AI Adoption Consultation 2026 | The 4 Advisor Types and 3 Axes

Someone in the management meeting has said the company should start using generative AI, and nobody in the room is quite sure what the first move is. So you search for AI adoption consultation, and what comes back is page after page of development company listings. You close the tab, and nothing moves. At the Thai sites of Japanese manufacturers, we see that exact state persist for months at a time. This article sets out the 4 types of advisor you can approach, the 3 axes that tell you which of those types fits your company right now, and the sequence that gets you from where you are to a first conversation that actually goes somewhere.

Why the search for an AI adoption consultation stalls before it starts

Start by taking apart the reason no advisor gets chosen. Once that is clear, what to look into next becomes visible.

Approaching a development company before the problem has words does not work

The biggest single reason no advisor gets chosen is that the person doing the choosing has not yet put their own problem into words. There is a general sense that AI ought to be able to do something. What has not been decided is which business, which step of it, and what specifically should change. Approach an AI development company in that state and the first question you receive is what kind of system you have in mind. You cannot answer it, the conversation goes nowhere, and you leave with a rough ballpark figure and nothing else.

We would not describe that as the buyer being underprepared. We would describe it as a mismatch in who was approached. A development company exists to build projects whose requirements are settled, which puts a requirement-free conversation outside the work it is set up to do. There are advisors whose entire purpose is the stage before requirements exist. They are simply not the ones who dominate the search results.

The word consultation means something different depending on who receives it

The second thing that gets missed is that the same word, consultation, buys you completely different things depending on the party on the other side of the table.

Some advisors will work through the prioritization of your problems with you from a standing start. Others open the conversation assuming your requirements are already fixed and move straight to how the thing gets built. Others again exist to grow AI capability inside your own company, and design their involvement around transferring the technology to your people. None of these is superior to the others. They are aimed at buyers standing at different points on the same road. The trouble is that search results present all of them under one undifferentiated banner, which leaves you with no basis on which to pick.

The market is genuinely moving, which is exactly why the entry point matters

None of this is an argument for rushing. It is still worth knowing what is happening around you.

According to the Global AI Diffusion report and the Work Trend Index 2026, published by Microsoft on 10 June 2026 at Microsoft AI Tour Bangkok 2026, AI adoption among workers in Thailand grew 36.4% year on year, far ahead of the global average of 17.8%. That places Thailand second worldwide for growth rate, behind South Korea at 43.2%. The same research puts Thailand’s overall AI adoption rate at 12.4%, up from 9.1% at the time of the previous study. It also reports that 32% of enterprise data workers in Thailand use AI, twice the global average, and that 51% of Thai business leaders have a clear AI strategy, again around twice the global average. On the infrastructure side, Microsoft has announced investment of more than USD 1 billion, roughly 35 billion baht, in cloud and cloud-based AI infrastructure in Thailand across the period from 2026 to 2028.

A second study is worth putting beside it. The Unlocking Thailand’s AI Potential 2026 report published by AWS finds that 43% of Thai businesses now use AI on an ongoing basis, up from 32% the previous year, which the report describes as 34% year-on-year growth. On that basis an estimated 220,000 companies adopted AI for the first time during the preceding twelve months. The same report puts the share of Thai small and mid-sized enterprises engaged in AI adoption at over 70%, above the regional average.

Change the population being measured, however, and the picture changes with it. Research conducted in 2024 by ETDA, the Electronic Transactions Development Agency of Thailand, covering 580 companies, found AI adoption across Thai business as a whole standing at only 18%. That same body of research, looking at the manufacturing sector as a separate population, expects AI adoption there to expand to 15% by 2030. Because 18% for business overall and 15% for the manufacturing sector are drawn from different populations, do not read the smaller number as a decline. The research also reports that 84% of companies already using AI perceive a productivity gain, up from 81% the previous year, and that 71% perceive higher revenue, with average growth of 19%.

The point we want to press here is that these figures must not be lined up against one another or added together. The Microsoft research surveys workers and business leaders. The AWS report measures ongoing use at company level. The ETDA study covers business as a whole across a sample of 580 companies. The research bodies differ, the populations differ, and the definitions differ. The phrase AI adoption rate points at something different in each case, so whenever you quote one of these numbers in an internal document, state which study it came from and which population it describes.

What matters more than the differences between the numbers is the direction they all point in. Companies in Thailand engaging with AI are clearly increasing, and the supply side, meaning the vendors and consultancies who receive these enquiries, is expanding to match. Another way to put that is that now that there are more options, the choice of entry point does more to determine the outcome than it used to. A Southeast Asia regional report published by the Japan-China Investment Promotion Organization makes a similar observation about generative AI in Thai business, noting that a large share of companies have either adopted it or plan to.

AI adoption consultation falls into 4 types of advisor

This is the core of the article. Advisors on AI adoption divide into 4 broad types according to the role they play. Hold that classification in your head and you can place any company appearing in your search results.

Strategy and consulting firms | for when the problem is still vague

The first type is the strategy and consulting firm. These advisors take the conversation from a point where nothing has been decided about what AI should solve, and work with you through an inventory of your operations, a list of candidate applications, prioritization, and the design of a PoC.

The value of this type lies in the fact that what you receive is not a system but the material on which to base a decision. Where AI is likely to produce results in your business, and equally which parts of your business are not suited to it yet, gets laid out for you on the basis of your actual data and your actual organization. Because the absence of settled requirements is the premise of the engagement rather than an obstacle to it, there is no need to feel awkward about having nothing decided.

What you should also expect is that engaging this type usually means commissioning the build separately, so the fee sits on top of build cost rather than inside it. We have set out how consulting engagements divide into types and how the fees are structured in the 4 types of generative AI consulting and the 5 layers of cost, which is the right thing to read once you have narrowed your choice to this type. Here we treat it purely as one of the 4.

AI development companies and contract developers | for when requirements are settled

The second type is the AI development company or contract development firm. These advisors take over once you have a reasonably clear picture of what is to be built, and carry out the actual construction and implementation.

This type performs best in proportion to how concrete your requirements are. The corollary is that approaching them while requirements are still vague tends to burn time purely on alignment. Before you make contact, put the target business process, the current transaction volumes and the state you are aiming for into words, and the very first meeting becomes a specific one.

Once the candidate list has been narrowed to two or three firms, what to examine in the contract and the quotation is covered in how to choose an AI development company and where the risk sits in contracts and quotations. This article deals with the stage before that, choosing which type of advisor to approach at all, so switch across once your shortlist exists.

One general point on evaluating development companies is worth carrying into the conversation. It is considered useful to ask whether the firm can speak concretely about failures as well as successes among its projects in your industry. Where only success stories come out, that may indicate limited real experience on the ground. AI is also not a matter of system development alone. Data, security, operations and governance all feed into whether it works, which means the decisive quality is comprehensive design capability, and it is considered important to pick a partner able to support you continuously from PoC through production rollout and into operational improvement.

Cloud vendors and large system integrators | for building on your existing IT estate

The third type routes the conversation through a cloud vendor, one of its certified partners, or a large system integrator. Where you are considering AI as an extension of a cloud platform or groupware suite your company already runs on, this path involves the least friction.

The defining characteristic of this type is that compatibility with your existing IT estate is guaranteed from the outset. Identity, permissions and log retention, all of which become heavy work if they have to be rebuilt later, sit on machinery you already have. The flip side is that the conversation starts from what the product covers, which makes it harder to press the prior question of whether your problem is really one that AI should be solving at all.

This article takes no position on which cloud vendor is better than another. That is not what decides the matter. What decides it is the current state of your own information systems. If your group has already standardized on a particular platform, approaching that platform’s own channel first is the cheapest way there is to gather information.

Insourcing support providers | for making internal AI development self-sustaining

The fourth type is the insourcing support provider. Rather than building the thing for you, these advisors work alongside your team with the transfer of technology as the explicit goal, so that your company ends up with people who can handle AI themselves. It suits companies that want to treat internal AI development as a continuing capability rather than a one-off project.

Choosing this type rests on two preconditions. There have to be people inside the company you can develop into that role, and those people have to be able to commit a defined amount of time rather than fitting it around a full existing workload. Declare an insourcing goal without both in place and you arrive at the end of the support period with nobody able to take the work over.

Which layers you hold internally and which you leave outside is set out in AI insourcing support and how to decide where each layer belongs. Once you are leaning toward insourcing, work through the split of layers there. In this article we keep the type as one entry among the 4.

The 4 types side by side

Laying the 4 types out against the same axes makes it much easier to see where your own enquiry belongs.

The most useful column in that table is the one on the right. Because the amount of information each type needs before it can help you differs, you can work backwards, choosing your advisor on the basis of how much material you actually have in hand. If all you have is a sense that something is wrong, the natural move is to start with the type that needs the least.

What you start generative AI with depends on the state you are in

With the types understood, the next question is which one describes your own situation. Three axes settle it.

Axis 1 | can the problem be stated in words

The first axis is whether the problem you want solved can be expressed at the level of a specific business process. The test is simple. Can you say, in one sentence, which department, which task, roughly how many hours a month it consumes, and what you want to happen instead?

If you can, your problem sits on the clear side. If you cannot, that is not a shortcoming. It only means the inventory of your current operations has not been done yet. Because there is a type of advisor for whom that inventory is itself the engagement, sitting in that state and making the approach anyway moves you faster than stalling while you try to force the wording on your own.

Axis 2 | is there anyone inside the company who has touched AI

The second axis is whether anyone in the company has actually used an AI tool. The bar here is not a technologist capable of developing models. It is somebody who has used generative AI tools in the course of their work and has developed a feel for what they can and cannot do.

Whether that person exists changes the quality of every conversation you have. With them, you can judge internally whether a proposal is realistic. Without them, you have no way to validate a proposal in house, which makes it safer to talk to several advisors and set what each one says against the others.

Axis 3 | is there a rough sense of budget

The third axis is whether the order of magnitude has been settled. It does not need to be an approved budget. What matters is whether you can see the size of number your company would be able to sign off.

Enquiries are perfectly possible without one, but the proposals you receive will lack resolution. Some people believe that withholding a budget figure extracts a better proposal. In practice we find the opposite is usually true. When the order of magnitude is unknown, the other party has little choice but to propose the safest configuration, which means the larger one.

Reading the 3 axes together to find the type that fits

The table below maps combinations of the 3 axes onto the 4 types.

What the table shows is that every row where the problem is still vague lands on either a consulting firm or a cloud vendor. Conversely, the insourcing support provider only becomes a candidate on rows where all 3 axes are satisfied. We receive a great many enquiries that open with a desire to insource, but setting insourcing as the goal before the 3 axes are in place leads directly into the failure pattern described later in this article.

What you get asked in a first conversation, and what to bring

Once you have a sense of who to approach, the next task is preparing for the first meeting. That does not mean producing a thick document.

There are essentially 4 questions

What gets asked in a first discussion is broadly common across the types. The current process, the sense of what is wrong with it, a rough budget, and the state you are aiming for.

The current process does not have to be a diagram. A bulleted account of who does what in what order works perfectly well. For the problem itself, name concretely where the time goes and where the mistakes happen. The target state is ideally expressed as a KPI, but for a first meeting something at the level of wanting this check to take half as long is enough to work with.

With nothing else in place, a sense of the problem is still enough

This is the point we most want to underline. Even with 3 of those 4 blank, a strategy and consulting firm or a cloud vendor or large system integrator will take the conversation as long as you can articulate what is wrong. Turning that articulation into something usable is, in fact, precisely what they are for.

We often see companies postpone the conversation until they are properly prepared. The day on which a company becomes properly prepared on its own rarely arrives. Spending six months completing an internal inventory before making contact gets you started later than making contact once the problem fits on a single page.

Why opening with how to choose generative AI tools is the wrong entry

A good number of people open a first conversation by asking which tool they should be using. Our view is that the choice of generative AI tool is not something to settle at this stage.

The reason is that tool selection is subordinate to the definition of the problem and to your organization. Whether the data involved can leave your network, whether integration with an existing business system is required, how many people will actually use it. Once those are settled, the field of viable tools narrows on its own. Start from the tool instead and you end up reshaping the problem to fit what that tool happens to do, which pushes the thing you originally wanted to solve into the background.

Comparing tools belongs after the problem and the organization are settled. Rather than asking an advisor which tool is best, try asking how far the options narrow given this problem and this organization. How specific the answer is will also tell you a good deal about how much real experience the other party has.

The usual sequence from first conversation to first work

Knowing the order in which things tend to unfold after a first conversation makes it much less likely that you lose your nerve partway through.

First interview, then PoC, then production design

The usual sequence runs from an initial interview, through PoC design, through trying something small, to production design. The initial interview shares your current state and your problems. On that basis, the areas most likely to produce results are narrowed down and tried within a deliberately limited scope. The results of that trial then feed the production design and the investment decision.

The advantage of this order is that the material for the investment decision comes from your own real data. Other companies’ case studies are useful as reference, but they carry nothing about the condition of your data or the habits of your operations. Treat the small trial as the step that measures that difference.

Do not ask for a company-wide rollout figure at the first meeting

What follows is our own view from the projects we have supported. Asking, at the first meeting, for the total cost of a company-wide rollout is something we would advise against.

There are two reasons. First, a total produced before the problem and the scope are settled has to rest on large assumptions, which means it will never be precise enough to take into an internal approval process. Second, we have watched that large number take on a life of its own inside a company, leaving behind nothing but the conclusion that AI is expensive, at which point the evaluation stops.

What to ask for early on is not the total but the cost and duration of a deliberately small trial. Because that scope carries limited assumptions, the estimate that comes back is far more accurate. Then, once the small trial has produced results, use those measured figures to size the company-wide rollout. Numbers arrived at in that order are numbers you can defend internally.

What is specific to AI adoption consultation at a Thai site

From here the discussion moves to Thailand. The Thai site of a Japanese manufacturer carries a decision that a company operating only in Japan never faces.

The IT department at head office, or a vendor here in Thailand

The most common source of hesitation is whether to raise the question with the information systems department at the Japanese head office or to approach a Thai vendor directly.

Our practical view is that this is not a choice between two options. It is a division of labour. Head office owns company-wide policy, meaning the rules governing generative AI use, the standards for handling data, and budget approval. The local site owns implementation, support in the local language, and the work of embedding the result in day-to-day operations.

Proceed without settling that division first and you get stalls in both directions. Go only to head office and a configuration arrives that does not reflect how the site actually works, so nobody uses it. Go only to local vendors and the result fails to line up with head office policy, so it is sent back at the approval stage. Both are avoidable simply by agreeing the division of labour before any conversation begins.

Concretely, before you start talking to anyone locally, confirm whether head office has a generative AI usage policy and, if it does, how far its prohibitions extend. If there is no such policy, then proceeding on the confirmed basis that none exists is itself the right move. We have seen sites run a local PoC all the way through without doing this, only to discover afterwards that it conflicted with a head office rule, sending the whole thing back to the beginning.

The local supply of advisors is growing

As noted above, the Microsoft research puts AI adoption among Thai workers at 36.4% year-on-year growth, second worldwide behind South Korea at 43.2%. Set against the global average of 17.8%, the pace of movement in Thailand is obvious. On the company side, the AWS report finds 43% of Thai businesses using AI on an ongoing basis, with over 70% of small and mid-sized enterprises engaged in adoption.

The UOB Business Outlook Study 2026 adds that Thai small and mid-sized enterprises treat resilience as a management discipline, that they are the most advanced adopters of AI in the region, and that over 80% plan overseas expansion within the next 2 to 3 years.

Supply has grown to match that demand. Compared with a few years ago, the range of parties you can talk to in Thailand has widened considerably. But a wider supply also means a wider spread of track records. That is precisely why establishing which of the 4 types a given company belongs to is the first thing to do.

Confirm local-language support before you sign

The other thing we would ask every Thai site to check is support in Thai.

AI adoption does not end when the thing is built. It produces results because people use it daily, and those people are local staff. If the explanation of how to operate it, and the desk they turn to when something is unclear, are not available in the local language, it will not take root. Confirm before signing which language each of three things is delivered in: the manuals, the training, and the enquiry desk after go-live.

Do not settle for an answer of yes, we can accommodate that. Push further and ask whether the person who will actually respond is permanently assigned or arranged case by case, and the real situation becomes visible. This is not a matter of optional comfort. In our view it is one of the conditions that decides whether the investment ever pays back.

Common failures when no advisor is consulted at all

What happens when you proceed without choosing an advisor? Two patterns come up repeatedly.

Commissioning a development company while the problem is still vague

The first is placing an order with an AI development company while the problem remains unarticulated.

What follows contract signature is a period of requirements alignment. The development company cannot start until requirements are fixed, so it runs interview after interview. But because the buyer has not settled what it wants either, the direction shifts at every meeting. The result is several months consumed by requirements alignment alone, with cost accruing throughout.

The difficult thing about this pattern is that neither side is at fault. The buyer is evaluating in good faith and the development company is interviewing carefully. Nothing moves because a party built around the assumption of settled requirements was approached at a stage where the requirements were not settled. It is a mismatch at the entry point.

Aiming for insourcing with no technology transfer plan in place

The second is setting internal AI development as the goal without deciding at the outset who receives which piece of technology.

With external support, the system does start working. But the design and the implementation are done by the support side, and the internal members do little beyond attending the meetings. When the support period ends, what remains inside the company is a working system and nobody able to explain what is inside it. Every modification and every operational improvement has to be commissioned externally, and the original purpose of insourcing goes unmet.

Both patterns are decided at the entry point, before the project starts moving, rather than after. For the structural reasons that projects stall once they are already under way, we have written separately about why 95% of generative AI projects stall after implementation begins, which is the piece to read if you are already committed and going nowhere. This article stays firmly on the side of choosing an advisor before you commit.

A checklist to run before you make contact

These are the items to confirm internally before you approach anyone. They are written at a level you can take straight into a meeting.

• Can you state the problem you want solved as one sentence covering which department, which task, and what should change?
• Do you know roughly how many hours a month that task consumes?
• Is there anyone in the company who has used a generative AI tool in the course of their work?
• Is that person in a position to give the evaluation a meaningful share of their time?
• Can you see the order of magnitude of budget your company would be able to approve?
• Can you express the target state in measurable terms, such as time saved or errors reduced?
• Have you confirmed whether head office has a generative AI usage policy?
• If it does, do you know which categories of data it prohibits you from handling?
• Have you agreed the division of labour between head office and the local site, meaning who sets policy and who implements?
• Have you established which of the 4 types a prospective advisor belongs to before making contact?
• Are you prepared to ask, at the first meeting, for the cost and duration of a small trial rather than a total?
• Do you have an item on your list for confirming which language the manuals, the training and the post-go-live desk are delivered in?

Approach an AI development company while the first five are unanswered and your time will go on requirements alignment. In that case, start with a strategy and consulting firm or with the channel of the cloud vendor you already use. Equally, proceeding at a Thai site without checking the three items covering the head office generative AI policy, the head office and local division of labour, and the scope of local-language delivery makes a stumble very likely at either the approval stage or the adoption stage.

Frequently asked questions

Where should we go for an AI adoption consultation?

It depends on the state you are in. If the problem has not yet been put into words, a strategy and consulting firm or the channel of the cloud vendor you already use is the right fit. If what is to be built has been decided, an AI development company or contract developer. If you want the capability to stay in house, an insourcing support provider. Make the judgement on 3 axes: whether the problem can be stated in words, whether anyone internally has touched AI, and whether a rough budget exists. Where even one of those 3 is missing, entering through a type that accepts a vague starting point moves you faster than entering through a development company that assumes settled requirements.

What should we start generative AI with?

Start with an inventory of your operations rather than with tool selection. Write down which task in which department consumes time and where the mistakes occur, then narrow the list to one or two areas where results look likely. If you cannot get that far internally, there are advisors for whom the inventory itself is the engagement. Making contact once the problem fits on a single page gets you started sooner than waiting until you are fully prepared.

What should we look at first when choosing generative AI tools?

We would recommend settling your own constraints before comparing features. Whether the data involved can leave your network, whether integration with an existing business system is required, and how many people will use it. Once those 3 are settled, the field narrows on its own. Start from the tool and you end up bending the problem to fit what that tool does, which pushes the thing you actually wanted to solve into the background. Rather than asking an advisor which tool is best, ask how far the options narrow given this problem and these constraints.

Can internal AI development be done entirely in house?

It can if the preconditions are met, but we would avoid setting it as a goal when they are not. There are 3 preconditions. People inside the company you can develop into the role, those people being able to protect a defined number of hours rather than fitting the work around a full existing role, and a plan settled before support begins for who receives which piece of technology. Declare insourcing without those 3 and you finish the support period with a working system and nobody able to explain what is inside it. Which layers you hold in house is a design question to work through separately, once you are leaning that way.

At a Thai site, should we consult the Japanese head office or a local vendor?

Neither exclusively. Think in terms of a division of labour. Head office owns company-wide policy, meaning the generative AI usage rules and the data handling standards, plus budget approval. The local site owns implementation, local-language support, and embedding the result in daily operations. Before you begin talking to anyone locally, confirm whether head office has a generative AI usage policy and what it prohibits. We have seen sites skip that check, run a local PoC to completion, and then find that it conflicted with a head office rule, putting them back at the start.

Summary

Here are the points this article has covered on choosing where to go for an AI adoption consultation.

• The reason no advisor gets chosen is not inadequate preparation. It is a mismatch at the entry point, approaching a type that assumes settled requirements at a stage where requirements are not settled.
• Advisors sort into 4 types: strategy and consulting firms, AI development companies and contract developers, cloud vendors and large system integrators, and insourcing support providers.
• Because the 4 types need different amounts of information before they can help, you can work backwards and choose on the basis of what you actually have in hand.
• Judge your own state on 3 axes: whether the problem can be stated in words, whether anyone internally has touched AI, and whether a rough budget exists.
• Where the problem is still vague, the fit is a consulting firm or a cloud vendor. The insourcing support provider only becomes a candidate when all 3 axes are satisfied.
• A first conversation covers 4 things, the current process, the problem, a rough budget and the target state, but it will still work if only the problem has been articulated.
• Choosing generative AI tools belongs after the problem and the constraints are settled. Start from the tool and you end up fitting the problem to the tool.
• The usual sequence runs from initial interview through PoC design and a small trial to production design, and asking for a company-wide total at the outset is best avoided.
• At a Thai site, do not choose between head office and the local vendor. Split the work, with head office owning policy and budget approval and the local site owning implementation and local-language support.
• The Microsoft research puts AI adoption among Thai workers at 36.4% year-on-year growth, second worldwide, and the AWS report puts ongoing AI use among Thai businesses at 43%, so the local supply of advisors is growing with it.
• These studies differ in both research body and population, so when quoting one internally, always state which study and which population, and never line them up for comparison.

The first thing to do is not vendor comparison and not collecting quotations. It is three things you can complete entirely on your own. Put the problem you want solved into a single sentence, identify one person internally who has touched AI, and establish the order of magnitude of budget. Once those 3 are in place, the tables in this article narrow the field of advisors for you.

TOMAS TECH supports digital transformation on the shop floor for Japanese manufacturers operating in Thailand, including the PEGASUS production management system. On AI we are just as happy to take the earlier questions, such as where you should even be directing the enquiry, or how to reconcile a local plan with a head office policy. You can reach out even at an early exploratory stage, before anything has been decided, through our contact page.

References

• Thailand Business News – Thailand ranks second worldwide for AI adoption growth, Microsoft reports
• SME Asia – Thailand’s AI use surges to 43% but most firms still struggle in adoption
• ThaiPR – UOB Business Outlook Study 2026 on Thai SME resilience and AI adoption
• HR NAVI – Points to confirm when choosing a generative AI development company
• JCIPO – Southeast Asia regional report on generative AI adoption in Thai business