“We’ve collected about ten case studies from other companies. Which one is closest to us?” That question comes up regularly at Japanese-owned plants in Thailand. The material handed over is almost always sorted by industry — automotive parts, electronics, food, metal fabrication. Yet picking the case study from the closest industry almost never makes the project go the way the case study did. What actually matters when you read shop floor AI use cases is not the industry. It is the type of data that plant already had before the project started. This article shows you how to sort the cases on your desk into four data types and map them onto your own plant, using a single decision axis.
Why searching for shop floor AI use cases by industry leads you wrong
Collecting case studies is genuinely useful for building internal consensus. The sentence “a competitor in our sector is already doing this” moves an approval request one step forward. The problem starts when you try to use that same case study as evidence that your plant can reproduce the result. A case chosen because the industry is similar tells you almost nothing about reproducibility. The reason is simple. A published case study describes the outcome. It does not describe the preconditions that made the outcome possible.
Case studies report results, not the preconditions behind them
Nearly every published implementation story follows the same shape. There was a problem, AI was introduced, results followed. That three-part structure is readable and perfectly valid as an article. But it systematically omits one thing — what that plant already had on the day it decided to proceed.
The moment you try to reproduce a case, you need the information below. And it is almost never in the article.
| What the case study tells you | What the case study leaves out |
|---|---|
| Defect rate fell, labour hours dropped | How many years of data had accumulated before the project |
| An AI camera was installed | Whether lighting, fixtures and camera position were already fixed |
| The system learned from expert judgement | Who labelled the ground truth, and how many hours it took |
| It is used on the shop floor | Which existing screen or form the output was embedded into |
| It went live in six months | How many people were on data work as a real job, not a side task |
| Head office provided support | Whether head office or the local site owned the master data |
| It was rolled out company-wide | How many times the first process had to be rebuilt |
The right-hand column is the actual set of variables that decides whether an AI project succeeds. If you read only the left-hand column and conclude “we could probably do the same,” those right-hand items will surface one by one as problems after you start. When you read shop floor AI use cases, the thing to look for is not the result figure. It is the set of preconditions the plant held before the case began.
Go one level deeper and those preconditions split into two kinds. The first is the data precondition — what format of data existed, over what period, at what quality. The second is the organisational precondition — whether someone inside the company could decide what “correct” means, and whether the shop floor had a place to receive the output. Organisational preconditions can be built with effort and design in about three months. But when the data precondition is missing, you cannot go back in time and create the data. That is the decisive difference.
Identical equipment, no data, no reproduction
Take a concrete example. Three plants each own the same injection moulding machine, same manufacturer, same model number. The equipment is identical. Now apply a case study titled “predicting moulding defects with AI.”
Plant A started collecting machine signals through a gateway three years ago. Temperature, pressure and cycle time are stored at one-second intervals for every moulding cycle. The date and time of each defect, plus the lot number, can be matched against inspection records. This plant can genuinely do something close to the case study, because both the normal data and the abnormal data needed for training already exist.
Plant B displays the same values on the machine’s own panel but stores nothing. Twice a day, a line leader copies a representative value onto a paper log sheet. This plant can do the same thing eventually, but it first needs a period to accumulate data. If the process throws an anomaly only a few times a month, it will take six months to a year before enough abnormal examples exist to train on. The line in the case study that reads “results within three months of go-live” simply does not apply here. It does not apply because of time, not because of capability.
Plant C has data, but the recording format changed every time equipment was swapped or a mould was modified, and nobody can now say which data was captured under which conditions. This is in fact trickier than Plant B, which has nothing. Data that exists but cannot be used burns investigation hours before anyone even establishes that it is unusable.
The three plants have identical equipment, sit in the same industry and make similar products. Even so, only Plant A can reproduce the same case at the same speed. The difference is not industry. It is the presence and quality of data. Which is exactly why sorting case studies by industry gets you nowhere.
| Plant | Equipment | State of the data | Chance of reproducing the same case | First thing to do |
|---|---|---|---|---|
| Plant A | Identical | 3 years, 1-second interval, linkable to defect records | High. Timeline close to the case study | Narrow to a single target process |
| Plant B | Identical | Only representative values on paper log sheets. No time series | Medium. Needs a collection period first | Build the collection mechanism first |
| Plant C | Identical | Data exists but conditions unknown and formats inconsistent | Low. Investigation eats the schedule | Inventory what was captured under which conditions |
What the 2026 numbers from Thailand and Japan say about getting stuck at the basic stage
“It never goes the way the case study did” is not a quirk of one plant. It shows up clearly in the statistics. Line up the surveys published in 2026 and the same structure appears.
According to the AWS research report “Unlocking Thailand’s AI Potential 2026,” AI adoption among Thai companies reached 43%, a sharp rise from 32% the previous year. By sector, finance is at 65% and IT at 64%, while manufacturing sits at 48%. On the numbers alone, roughly half of Thai manufacturing is using AI in some form.
But the same report also breaks down what that use consists of. Among adopting companies, 74% remain at the “basic” stage — using off-the-shelf tools such as ready-made chatbots that work out of the box. Only 9% have reached the “advanced” stage, where models are built on the company’s own data and embedded into business processes. Beyond that, only 19% of organisations have an internal governance policy for AI use, and 56% of executives named a shortage of skilled people as a challenge.
A global Microsoft study, presented at AI Tour Bangkok 2026, put Thailand’s growth rate in AI adoption at 36.4% year on year, second in the world behind South Korea. At the same time, 87.6% of the general population is not yet using AI at all. Growth is fast, but the base is still narrow. Those two facts are not in conflict.
The Japanese numbers point the same way. The 2026 White Paper on Manufacturing Industries, approved by cabinet on 29 May 2026, reports that roughly 70% of manufacturers capture data from their production processes, while only about 40% are getting measurable value from that data. There is a gap of roughly 30 percentage points between capturing and using. Japan’s Ministry of Economy, Trade and Industry has also proposed a “manufacturing AX hub” concept, gathering machining and operating data in order to implement AI models on top of it.
The primeNumber “AI and Data Utilisation Survey 2026,” published on 17 July 2026 with 373 respondents, found that 64.9% of respondents have high expectations of AI, while only 16.4% have obtained a clear result. On data quality, 26.2% said it was “a challenge across the whole company” and 13.9% said it was “not organised at all.”
| Survey | Key figures | What it tells you |
|---|---|---|
| AWS “Unlocking Thailand’s AI Potential 2026” | Thai company AI adoption 43% (32% prior year), manufacturing 48% | The entry point has widened |
| Same report, stage breakdown | Basic stage 74%, advanced stage 9%, governance policy in place 19% | People are using AI but have not reached their own data |
| Same report, challenges | 56% of executives cite a skills shortage | The blockage is people and operations, not technology |
| Microsoft global study | Thailand growth 36.4% year on year, second worldwide, 87.6% of population not using AI | Speed and breadth are separate questions |
| 2026 White Paper on Manufacturing Industries | Roughly 70% capture data, roughly 40% get value | There is a step between capturing and using |
| primeNumber survey 2026 | Expectation 64.9% versus clear results 16.4%, data quality a company-wide issue for 26.2% | The gap between expectation and result overlaps with data quality |
Put those numbers side by side and a shared structure emerges. Starting to use AI has become easy. Connecting it to your own shop floor data has not. An off-the-shelf chatbot needs none of your data, so anyone can start today, and adoption rates climb accordingly. But visual inspection, predictive maintenance and demand forecasting do not run without data produced by your own operation. That is where 74% stop and only 9% move on.
In other words, most of the reason a case study fails to reproduce has nothing to do with AI performance or vendor selection. It is the gap in data preconditions between the case company and yours. If that is true, then the axis for sorting case studies should be data, not industry.
Sort shop floor AI use cases into four data types
This is the core of the article. Take the third-party cases sitting on your desk and classify each one into one of the four types below. The classification criterion is a single question — what was the primary data this case needed in order to work?
- Type 1, images — still photos and video captured by a camera
- Type 2, time series — sequences of numeric values emitted at fixed intervals by equipment or instruments
- Type 3, documents and text — work instructions, drawing notes, daily reports, enquiries, chat logs
- Type 4, transaction figures — tabular records such as production output, shipments, inventory and cost
These four differ completely in the data they require, where they get stuck and how long they take to show results. Put the other way round, if the type matches, your prediction about reproducibility will hold even across different industries. A visual inspection case at a food plant in Thailand and a visual inspection case at an electronics plant in Japan sit in different industries, but both are Type 1, so the preparation required is almost identical. Meanwhile, two cases from the same automotive parts plant — visual inspection (Type 1) and demand forecasting (Type 4) — share nothing at all in what they require.
Start by comparing the four side by side.
| Type | Primary data | Where the data comes from | Speed to get started | Burden on the shop floor |
|---|---|---|---|---|
| 1. Images | Still photos, video | Cameras, usually newly installed | Slow, because reshoots happen | Large, labelling is required |
| 2. Time series | Temperature, current, vibration, pressure, kWh | PLCs, sensors, power meters | Medium, an accumulation period is needed | Small, collection can be automated |
| 3. Documents and text | Work instructions, daily reports, enquiries | Existing file servers and similar | Fast, the data usually already exists | Medium, organising is required |
| 4. Transaction figures | Production, shipments, inventory, cost | Production and sales management systems | Fast, the data usually already exists | Small, uses existing data |
The “speed to get started” column is not driven by technical difficulty. It is driven by whether the data is already in your hands. Types 3 and 4 are fast because most plants already hold that data. Type 1 is slow because most plants have not been accumulating product images.
Type 1, images — AI cameras, visual inspection, safety monitoring
This type has the most case studies, attracts the highest expectations, and shows the widest gap between the quotation and reality. It covers detection of scratches, chips and contamination, checking whether a part is present and correctly oriented, label placement, verification that operators are wearing safety equipment, and intrusion detection in restricted areas.
The defining characteristic of this type is that most plants do not yet have the data it needs. Unlike time series or transaction figures, very few plants have been quietly accumulating product images over the years. Reproducing a Type 1 case therefore means starting data collection from zero.
What makes it harder still is that “just capture something for now” rarely works with images. Change the lighting angle, the camera position, the background or how the product is placed, and the same defect looks like a different thing. It is entirely possible to collect several thousand images and have all of them become useless the moment the shooting conditions are re-fixed. The step that consumes the most time in Type 1 is not training. It is deciding and locking down the imaging conditions.
| Aspect | Detail |
|---|---|
| Typical applications | Visual inspection (scratches, chips, foreign matter), presence and orientation checks on assembly, label position, PPE compliance checks, intrusion detection |
| Data preconditions | Images of good and defective units. Fixed imaging conditions (lighting, angle, distance, background). A sufficient count of images for each defect category |
| Where it gets stuck | Defect images do not accumulate because defects are rare. Unstable imaging conditions invalidate the training set. The good/no-good boundary differs by inspector. Processing cannot keep up with line speed |
| Time to results | One to three months to build the imaging environment, two to six months to accumulate images and label them. Expect a year-scale effort before it replaces an existing inspection step |
The first thing to clear on the shop floor is the problem of the defect definition varying between people. If you show the same part to three inspectors and their verdicts split, training on that state will simply reproduce the split. Before AI enters the picture, the inspection criteria have to be fixed in writing and in physical limit samples — and that is quality assurance work, not technical work.
The other common mismatch of expectations hides behind the phrase “yield improved.” Visual inspection AI finds defects. It does not reduce them. It is effective at preventing escapes and cutting inspection labour, but lowering the occurrence rate itself requires improvement on the process side. When you read a result figure in a case study, work out whether it refers to escapes or to occurrence.
The step-by-step approach for this type, how to think about the number of images required, and how to run it in parallel with your existing inspection step are covered separately in how to implement AI visual inspection. If a case on your desk sorts into Type 1, that is the fastest next read.
Type 2, time series — anomaly detection, predictive maintenance, energy
This type uses sequences of values emitted by equipment at fixed intervals. Motor current, bearing vibration, oil temperature, pressure, cycle time, power consumption. Anomaly detection, predictive maintenance, detection of abnormal energy use and correlation analysis between quality and process conditions all sit here.
The character of Type 2 is that collection is easy to automate, but you cannot buy time. Once you connect to the machine signal, data accumulates without anyone touching it. The shop floor burden is among the smallest of the four types. But to learn what an anomaly looks like, anomalies have to occur. To predict failures on a machine that breaks twice a year, you either collect several years of those two events, or you design the system to treat anomalies as deviations from a normal state.
Plan a “predictive maintenance project in six months” while misreading this point, and six months later all you will have is normal data. So when you read a Type 2 case, always check when that plant started collecting data. In most cases it is not stated — and the fact that it is not stated is itself grounds to assume collection began years before the project.
| Aspect | Detail |
|---|---|
| Typical applications | Equipment anomaly detection, predictive maintenance, abnormal power consumption detection, correlation of process conditions with quality, cycle time variation monitoring |
| Data preconditions | Values recorded at a fixed interval. Identifiers for equipment and process, plus timestamps. Records of when anomalies occurred (maintenance logs, defect records) that can be matched against the signal |
| Where it gets stuck | Too few anomaly examples to train on. Equipment upgrades or mould changes alter the character of the data. Signals are available but “when it broke” exists only on paper. Alerts are so frequent that the shop floor stops looking |
| Time to results | One to two months to build the collection mechanism, six months to several years to accumulate enough data to train on. A plant that already has data can validate in two to three months |
What is most often overlooked in this type is that the record of when the anomaly occurred is the harder half. Sensor values accumulate automatically, but “we replaced the bearing on this date” and “defects spiked on this date” often live only on paper in maintenance logs and daily reports. A sequence of numbers with no ground truth attached cannot be trained on. In Type 2 preparation, the thing that actually needs work is frequently not the sensors but digitising the maintenance records.
The other trap is alert design. What can be detected technically and what the shop floor can act on are different things. A display that says “signs of anomaly detected” leaves the maintenance technician with no idea what to do. Which machine, which component, by when, and what action. Only once that is defined does it work in operation. Designing predictive maintenance and turning alerts into shop floor actions is covered in building a predictive maintenance system.
Type 3, documents and text — procedure search, enquiries, daily reports, multilingual
Work instructions, equipment manuals, past troubleshooting records, quality defect reports, comment fields in daily logs, internal enquiries. This type uses written information. It covers searching procedures, answering questions, summarising reports and converting between languages.
Of the four types, this one is most likely to get moving quickly. The reason is simple — most plants already hold these documents. Thousands of PDFs, Excel files and Word files are already sitting on the file server. No new sensors, no new cameras.
At Japanese-owned plants in Thailand, this type is particularly effective, because it is entirely normal for a Japanese original, an English version and a Thai version to coexist with nobody sure which one is current. The operator reads only Thai, the Japanese manager holds only the Japanese version, and the two say different things. Strictly speaking this is a document control problem that predates AI. But because the process of introducing AI forces you to designate a single authoritative version, document control gets fixed as a side effect.
| Aspect | Detail |
|---|---|
| Typical applications | Cross-document search of procedures and manuals, suggested responses during equipment trouble, similar-case search of past defects, daily report summarisation, multilingual reading |
| Data preconditions | Documents in electronic form. A settled answer to which version is current. Clarity on what each document covers (which machine, which product). If only paper exists, scanning and text extraction come first |
| Where it gets stuck | Multiple versions of the same document exist and the system answers from an obsolete one. Information inside drawings and photos cannot be picked up. Nobody has been assigned to guarantee the correctness of answers. The handling of confidential documents was not decided up front |
| Time to results | If documents are already digital, one to two months to trial. Around three months including version cleanup and permission design |
The most dangerous failure in this type is answering confidently from an obsolete version. An operator handed a superseded procedure may follow it exactly. The countermeasure is not technical but operational, and it comes down to deciding in advance which folder and which version is authoritative. That cleanup is work you should be doing with or without AI.
Note also that instructions embedded in drawings, and conditions visible in photographs, are not text and cannot be picked up by this type. Where drawing annotations matter to the process, Type 3 has to be combined with Type 1. How to build a system that searches and answers from internal documents, and how to draw the lines on permissions and confidentiality, is set out in detail in building RAG on factory technical documents.
Type 4, transaction figures — demand forecasting, production planning, inventory, cost
This type uses figures that already sit inside your systems in tabular form — production output, shipments, orders, inventory, cost, utilisation. It covers demand forecasting, support for production planning, inventory optimisation and analysis of what drives cost variance.
Like Type 3, this type has a high probability that the data already exists inside the company. Any plant running a production management or sales management system should have several years of history accumulated. Because it requires little or no new investment, it is a common choice for a first project.
That said, existing does not mean usable as is. What happens constantly in Type 4 is master data inconsistency. The same product carries several part numbers, the numbering scheme changed partway through, units are mixed between pieces and boxes, each site uses its own codes. This is not an absence of data. It is data that does not line up.
| Aspect | Detail |
|---|---|
| Typical applications | Demand forecasting, support for production planning, inventory optimisation, root cause analysis of stockouts and excess, understanding cost variance drivers |
| Data preconditions | Historical results, ideally two to three years. A unified item master. Consistent units of quantity. Retained event information such as special demand, shutdowns and production transfers |
| Where it gets stuck | The part numbering scheme changed partway through. Units are mixed. The effect of past special demand or disasters cannot be treated as outliers. A forecast is produced but nobody has authority to change the plan based on it |
| Time to results | With data in order, one to three months through validation. Add two to four months if master data cleanup is required |
The issue specific to Type 4 is who uses the number that comes out. Forecast accuracy can improve, but if the production plan is set by a planner at head office and the local forecast is treated only as a reference value, nothing about the business changes. When you read a case in this type, look past the result figure and search for whose decision changed because of the forecast. A case that does not say is a case where accuracy improved and the business did not.
How to read demand variation, and how much forecast accuracy you should actually be aiming for, is covered in implementing demand forecasting AI. Worth reading alongside this section if your case sorted into Type 4.
Three questions for sorting the cases on your desk
Now turn the four types into actual sorting work. For each case you hold, answer these three questions in order.
Question 1 — what was the primary data this case needed in order to work? Camera images, a sequence of values from equipment, documents, or a results table inside a system? If you cannot narrow it to one, the case combines multiple types. In that situation, treat the hardest data to obtain as the primary data. The difficulty of a combined case is pulled toward the harder side, never the easier one.
Question 2 — does your company already have data of the same type? Judge on “have,” not “could get.” “We could get it if we fitted sensors” is the same as not having it, because an accumulation period still lies ahead of you.
Question 3 — can you attach ground truth to that data? For images, the good/no-good verdict. For time series, the date and time each anomaly occurred. For documents, which version is authoritative. For transaction figures, the part number mapping table. Until someone is assigned to produce the ground truth, having the data does not make it trainable.
Only the cases that survive all three are worth evaluating for your own plant. A case that stalls at Question 2 becomes “not now, but possible in one to two years if we start accumulating data.” A case that stalls at Question 3 should be redirected from an AI discussion to an organisational one.
| Result of the questions | How to treat that case | What to do next |
|---|---|---|
| All three answered | Promising. Candidate for the first project | Narrow to one target process and move to validation |
| Stalls at Question 2 | Not this fiscal year. Medium-term candidate | Build only the data collection mechanism now |
| Stalls at Question 3 | An organisational problem, not a technical one | Secure the person and the hours to define ground truth |
| Type unclear at Question 1 | Combined type. Difficulty follows the harder side | Validate the harder type on its own first |
Three things plants that raised productivity with AI did beforehand
Once the sorting is done, the next question is how to proceed. From here on, the approach is the same regardless of type. When we join a project at a Japanese-owned plant in Thailand, these three are what we actually do first. Put the other way round, a project that skips these three will not go well even if the type selection was correct.
Narrow to a single process — process improvement AI does not start with horizontal rollout
The most common failure is targeting multiple processes and multiple lines from day one. The reasoning is understandable. If you are going to invest, you want the impact to look large, and a larger scope reads better in an approval request. But running several in parallel creates the following problems.
First, you lose the ability to tell where it got stuck. When something does not work, you cannot separate whether the cause is the data, the configuration or the way the shop floor operates. With a single target, the blockage can always be located.
Second, the burden on the shop floor arrives all at once. Labelling ground truth, checking screens, feeding back corrections — all of this is added on top of normal work. With one process, “this month is a bit busy” covers it. With five processes at once, normal work stops running and cooperation evaporates.
Third, the cost of rework multiplies by five. The first project always requires rework. Defects appear that nobody anticipated, the shop floor does not use it, the cut-off dates do not line up. With one project that is one round of rework. With five in parallel, you carry five simultaneously.
The criterion for narrowing is not the size of the expected benefit. It is whether you can identify the cause when it gets stuck. Concretely — a scope one person can hold in their head, a scope where the data originates in one or two places, and a scope where the person who checks the output is physically on that shop floor every day. Pick the process that satisfies all three. High-impact processes usually involve many stakeholders and fail these conditions.
Narrowing does not mean “try something small and stop there.” The purpose of the first project is not to produce a result. It is to make the estimate for the second project accurate. What the first project reveals is how dirty your data actually is, how many minutes per item ground truth labelling takes, and how the shop floor uses the screen. Once those three are known, planning from the second project onward becomes realistic.
Decide up front who produces the ground truth
Asking AI to make a judgement means someone has to decide which judgement is correct. Any project that has not settled who that someone is will stall partway through.
Three things are needed specifically.
First, a person with the authority to define correct. For visual inspection, the quality assurance member who can make the final good/no-good call. For predictive maintenance, the experienced maintenance technician who can say whether this vibration is abnormal. For work instructions, the engineering function that can declare which version is authoritative. If that person holds the role as a side duty and is already overloaded, the project will slip.
Second, allocated working hours. Ground truth labelling cannot be done in spare moments. Assigning good/no-good verdicts to a thousand images takes several hours even for someone experienced. Whether that time is recognised as work is a management decision, not a shop floor one. Leave it vague and ask for it “whenever you have a moment,” and the labels will not arrive.
Third, a rule for when judgements disagree. When two inspectors reach different verdicts, which one is adopted? Majority vote, the senior person’s call, or exclude both from training as “undecided”? Without that rule fixed in advance, work halts the moment a disagreement appears.
| Type | Who produces the ground truth | What the ground truth looks like | Rough scale of the work |
|---|---|---|---|
| 1. Images | Quality assurance, inspection staff | Good/no-good per image, defect category, location | Hundreds to thousands of images |
| 2. Time series | Maintenance, production engineering | Date and time of each anomaly, and the machine involved | Mostly matching against past maintenance records |
| 3. Documents | Engineering, document control | Designation of the authoritative version, plus expected Q&A | Dozens of anticipated questions at minimum |
| 4. Transaction figures | Production control, sales | Part number mapping table, explanation of outliers | Master data cleanup is the real work |
Read that table and one thing becomes clear — the department you have to involve is completely different depending on the type. Type 1 means quality assurance, Type 2 maintenance, Type 3 engineering, Type 4 production control and sales. The org chart for an AI project is determined by the type you chose. Not one of the four can be driven by the IT department alone.
How you will measure the effect needs to be decided at the same moment. If you do not put into words what counts as success before you start, opinions will diverge once the system is running. Measurement design is covered in how to measure the effect of AI implementation, and reading it at the approval stage makes later explanations considerably easier.
Build the screen the shop floor actually uses — the number one reason AI adoption fails to stick
A technically successful project that nobody uses is a common ending. In most cases the cause is that no place was built to receive the output.
The verdict sits in a cloud console, but there is no PC on the shop floor. Alerts arrive by email, but operators do not read email. The forecast comes out as a CSV, but nobody has been designated to revise the plan from it. None of these are technical failures. They are gaps in the design.
What actually works on the shop floor looks like this.
- Add to a screen that already exists. Adding one field to the production instruction screen or inspection terminal an operator already looks at every day gives a far higher adoption rate than adding one more system.
- Display the decision, not the number. Not “anomaly score 0.87” but “spindle on machine 3, inspect this week.” Do not hand the job of interpreting numbers to the shop floor.
- Build a path to report errors back. When the AI verdict is wrong, is there a place where the shop floor can say “this one is wrong” in a single tap? Without it, accuracy stays frozen at its initial level and the shop floor concludes it does not work and stops looking.
- Match the language. Put an English screen in front of a shop floor working in Thai and that alone is enough to kill usage.
At plants in Thailand, that last point matters more than people expect. Training delivered in English, a screen left in English at go-live, and nobody looking at it three months later — that sequence is not unusual. Present the decision, in the language the shop floor works in, in the place the shop floor looks every day. Only when all three line up are you standing at the entrance to adoption.
Adoption also requires involvement after go-live. Verdict drift during the first three months is normal, and without someone assigned to catch and correct that drift, shop floor trust erodes fast. How to structure operations after implementation, and who takes ownership of improvement, is set out in support for making AI adoption stick. In the survey cited earlier, 74% of adopting companies remained at the basic stage — and what separates those who move beyond it is this post-go-live design, far more than model accuracy.
Practical steps for starting shop floor AI at a Japanese-owned plant in Thailand
So far we have covered types and approach. Finally, here are the conditions that come into play specifically when you run this at a site in Thailand. Bring a plan written at head office in Japan and drop it in unchanged, and this is where it will snag.
Conditions specific to a Thai site — multiple languages, staff turnover, dual control with head office
Multiple languages is the first gate. There is a Japanese original of the work instruction, an English version and a Thai version. Operators read the Thai version, while the basis for judgement lives in the Japanese one. In any project handling documents (Type 3), nothing starts until you decide which of those three layers is authoritative. The same applies to screens — you need a design that separates the language for supervisors from the language for operators. At plants employing Burmese or Cambodian speakers, it becomes one level more complex again.
Staff turnover affects operational design. A design that stops the moment the person in charge changes — that is, one where the procedure exists only inside a particular individual’s head — will not survive at a Thai site. Monthly tasks need to be written onto a single sheet so that anyone taking over can perform the same work. It looks like an annoyance and is in fact one of the highest-return pieces of work available.
Dual control with head office comes up constantly. The item master exists on both the head office side and the local side, and fixing one leaves the other untouched. Forecasts and plans produced locally are overridden by a different system at head office. Introduce AI into that situation and “the AI number” and “the head office number” coexist, leaving the shop floor unsure which to believe. Agree with head office which number is authoritative before you start. It is not technical work, but skipping it guarantees you will come back to it.
| Condition specific to a Thai site | What it affects | What to settle before starting |
|---|---|---|
| Multiple languages (Japanese, English, Thai, sometimes a fourth) | Authoritative documents, screen display, training material | Which language is authoritative, and which screen appears in which language |
| Staff turnover | Continuity of operations | Monthly tasks documented, scope of handover defined |
| Dual control with head office | Master data, forecasts, actuals | Which number is authoritative, and the direction of updates |
| Shop floor IT environment | How output reaches people | Whether terminals exist on the floor, and if not, what to display on |
| Network and power stability | Gaps in data collection | How to handle missing data, whether local buffering is needed |
Our overall approach to implementation in Thailand, how to divide roles with local vendors, and how to explain the project to head office in Japan are collected in how to approach AI implementation in Thailand. Worth referring to when the local site is drafting the plan.
On budget, and why BOI and similar schemes should be checked for current terms
Now to cost. We will not quote a price range. The variation between projects is too large, and publishing a range invites misunderstanding. Instead, here is what actually moves the number.
| Cost item | What you are paying for | How it varies by type |
|---|---|---|
| Data collection mechanism | Cameras, sensors, networking, panel work, extraction from existing systems | Large for Types 1 and 2. Largely unnecessary for Types 3 and 4 |
| Data preparation | Ground truth labelling, master unification, version cleanup, inventory of historical data | Occurs in every type. Depends on master data condition for Type 4 |
| Model build and validation | Training, accuracy verification, rework when conditions change | Most iteration occurs in Type 1 |
| Shop floor screens and system integration | Display, notification, embedding into existing screens, multilingual support | Occurs in every type. Frequently overlooked |
| Operational launch | Training, correcting verdict drift over the first three months, documenting operating procedures | Occurs in every type |
When plants take quotations, the first line is where attention goes. But the lines where the number actually becomes unpredictable are the second and the fourth. Nobody can know the effort required for data preparation until the work starts and the contents are visible. And shop floor screens and integration with existing systems can shift by an order of magnitude depending on how those systems were built. Any project that proceeds with those two marked “to be quoted separately” will see its number move partway through.
On incentive schemes. The Thailand Board of Investment (BOI) operates a Smart and Sustainable Industry measure covering machinery upgrades, automation and robotics, and digital technology adoption, and applications concentrated in that measure during the first quarter of 2026. Applications in the digital and AI infrastructure field numbered 48.
However, specific terms such as the number of tax-exempt years or the deduction rate change from year to year, so we do not publish them here. The scope of qualifying investment is likewise reviewed. Build an approval request on assumed incentive terms and you may find the terms have changed by the time you file, collapsing the premise. Check the current terms and scope on the official BOI channels, and consult a specialist before filing if needed. When you build the approval case, make the plan stand up both with and without the incentive — that way it survives a change in terms.
A 90-day path to completing one project (days 0–30, 31–60, 61–90)
Finally, here is how to get the first project through in 90 days. These are the phases we use on live projects. The first 30 days can be done without a vendor present. In fact, projects where the client side pushed through those 30 days alone tend to move faster afterwards.
Days 0–30 — sort the cases you collected and pick one target
Four things happen in this period. First, sort the third-party cases on your desk into the four types. Second, apply the three questions from the previous chapter (what is the primary data, do we already have it, can we attach ground truth) and split each case into “promising,” “medium-term” and “organisational problem.” Third, choose one target process from those that remain promising — the criterion being not the size of the benefit but whether you can identify the cause when it gets stuck. Fourth, secure the person who will produce the ground truth, and secure their working hours.
Do not take equipment quotations during these 30 days. Take one and the figure takes on a life of its own before anyone has decided whether the equipment is needed.
Days 31–60 — run something on your own data, rough is fine
In the second month you actually touch the data. Do not build a finished product. The purpose here is to learn the true state of your own data. Specifically, confirm the following.
- Whether the data you assumed really exists, over the period and at the granularity you assumed
- How much missing data, duplication, mixed units and code mismatch there is
- How many minutes per item the ground truth labelling actually takes
- What proportion of cases produce split judgements
Once those four are known, the plan from month three onward can be built on real numbers. In many projects the original plan changes at this point. Changing is not a failure. It is the deliverable of this period.
Days 61–90 — put it on a shop floor screen and have people use it for two weeks
The third month is not a period for raising accuracy. It is a period for using it on the shop floor. Put the verdict on a screen the shop floor looks at every day, in the shop floor’s language, in the form of a decision. Then have people use it for two weeks and observe the following.
- Whether the shop floor is actually looking at it (if not, it is in the wrong place)
- Whether the shop floor is reporting back when a verdict is wrong
- What patterns appear in the feedback that comes back
- How many extra minutes are being added to normal work
The feedback that emerges over those two weeks becomes the material for the next round of improvement. Conversely, zero feedback is a warning sign. It usually means nobody is looking, not that everything is fine.
| Period | Main work | Definition of done | Vendor involvement |
|---|---|---|---|
| Days 0–30 | Sorting cases by type, selecting the target process, securing the ground truth owner | One process selected and the owner’s hours secured | Not needed |
| Days 31–60 | Confirming the true state of your data, rough validation, measuring the actual work time | The state of the data and the labelling time are known as numbers | Yes |
| Days 61–90 | Display on shop floor screens, two-week trial, collecting feedback | Feedback is coming from the shop floor and its patterns are organised | Yes |
What 90 days is aiming at is not a result. It is the ability to plan the second project from measurement rather than guesswork. From what we see on live projects, most plants stuck at the basic stage have never carried a first project all the way through. Carry one through and you learn the true state of your data, the load of ground truth labelling and how the shop floor reacts. At the moment those three are known, third-party case studies change from “something to refer to” into “something to compare against your own conditions.”
Frequently asked questions
Where should I look for shop floor AI use cases?
How you search matters more than where. Vendor case study pages, trade publications, exhibition presentations, public agency case collections — sources are plentiful. The problem is that all of them are organised by industry. Collecting cases from your own sector does not reveal the gap between those plants and yours.
The recommended approach is to search by data type rather than industry. Not “automotive parts AI case study” but “image inspection AI implementation” or “equipment data anomaly detection” — search by the data being handled. Then, for each case you find, confirm the three points: what is the primary data, does the same type exist in our company, and can we attach ground truth. A case that cannot answer those three is not decision material for you, however close the industry.
If I install an AI camera, can visual inspection be automated straight away?
Not straight away. Installing an AI camera is only one of the required steps. In practice, what comes first is fixing the imaging conditions (lighting, angle, distance, background), collecting images of good and defective units, labelling those images good or no-good, and unifying the good/no-good criteria among people in the first place.
The step that takes the most time is collecting defective images. The lower the defect rate, the fewer defect images are available to train on. For a defect category that appears only a few times a month, it can take close to a year to accumulate enough images. Note too that visual inspection AI is a mechanism for finding defects, not for lowering the occurrence rate. It works for preventing escapes and cutting inspection labour, but reducing occurrence requires separate improvement on the process side.
How much does process improvement AI cost?
We do not publish a price range, because the variation between projects is too large. Instead, here are the variables that determine the cost. There are five.
The first is the data collection mechanism, which is large in Types 1 and 2 where new cameras or sensors are required, and almost nil in Types 3 and 4 which use existing data. The second is data preparation — the effort for ground truth labelling, master unification and version cleanup. This cannot be estimated accurately until the work starts and the contents are visible. The third is model build and validation. The fourth is shop floor screens and integration with existing systems, where effort shifts by an order of magnitude depending on how those systems were built. The fifth is operational launch, which includes training and correction work over the first three months.
When you compare quotations, check whether the second and the fourth have been marked “to be quoted separately.” Those are the two places where the number moves.
Why does AI fail to stick on the shop floor?
In most cases, because no place was designed to receive the output. The verdict sits on a screen the shop floor does not open, the notification arrives by a channel the shop floor does not use, the display is in a language the shop floor does not read. A system that runs technically but goes unused can be explained by one of those three.
The other reason is the absence of a path to report errors back. Without a place where the shop floor can say “this one is wrong” when the AI verdict is off, accuracy stays frozen at its initial level and the shop floor concludes it does not work and stops looking. Whether you can assign someone to catch and correct verdict drift for three months after go-live is the dividing line. Make what you display an action too — “which machine, by when, do what” — not a score or a probability. The moment you hand the job of interpreting numbers to the shop floor, usage ends.
Can a small plant achieve results like the ones in AI case studies?
If you pick the right type, yes. Small plants even have some advantages — fewer processes, stakeholders sitting closer together, faster decisions. As noted above, the first project should target the process where you can identify the cause when it gets stuck, not the process with the largest benefit, so being small works in your favour as a condition.
As for which type to pick, starting from Type 3 (documents and text) or Type 4 (transaction figures), both of which use existing data, is the realistic choice. Neither requires new sensor investment, and validation can begin with what you already hold. Choosing Type 1 (images) as the first project, by contrast, means time and money on building the imaging environment and accumulating data, which is a heavy load for a small team. The survey finding that only 9% of companies have reached the advanced stage of building models on their own data does not break the figure down by company size. From what we see on live projects, the difference is not the size of the plant but whether the first project that connects to your own data was carried all the way through.
Summary
Third-party case studies mislead you when you select them by industry. Same industry, same equipment, same product — what decides whether the project goes the way the case study did is the data that plant already held before the case began. Published cases describe results. They do not describe preconditions.
So change the sorting axis from industry to data type. There are four — 1. images, 2. time series, 3. documents and text, 4. transaction figures. They differ in required data, in where they get stuck and in how long results take. Type 1 is a type most plants have no data for yet, and it starts with fixing imaging conditions. Type 2 can automate collection, but you cannot buy the time it takes for anomalies to accumulate. Types 3 and 4 have a high chance of starting on data that already sits inside the company.
The 2026 numbers show the same structure. AI adoption among Thai companies reached 43%, and manufacturing has come up to 48%. Yet across adopting companies, 74% remain at the basic stage of using off-the-shelf tools, and only 9% have reached the advanced stage of building models on their own data. In Japan, roughly 70% of manufacturers capture data from production processes while only about 40% get value from it. The entrance has widened, and progress stops at the connection to your own data. That is where we currently stand.
Once you have sorted the cases on your desk into the four types, apply the three questions to each one. What is the primary data? Does the same type of data already exist here? Can we attach ground truth to it? Only the cases that answer all three are worth evaluating. From there, narrow to one process, settle the ground truth owner and their hours in advance, and present the decision on a screen the shop floor looks at every day. Get that far in 90 days and the second project can be planned from measurement rather than guesswork. From what we see on live projects, what plants stuck at the basic stage lack is not technology but the experience of carrying that first project all the way through.
TOMAS TECH builds production management systems and shop floor data foundations for Japanese-owned manufacturers in Thailand. We welcome enquiries at the early evaluation stage — “we want to judge which of the case studies we collected could be reproduced here,” or “we want to first understand what our existing data could support.” Bring the case material you have been handed together with a list of the data your current systems can export, and we can start by sorting through which type each case belongs to and what is missing. Get in touch here.
References
- The Story Thailand — coverage of the AWS report “Unlocking Thailand’s AI Potential 2026” (2026-07-15)
- Thailand Business News — coverage of the Microsoft global AI adoption study (2026-06-10)
- Ministry of Economy, Trade and Industry (Japan) — “2026 White Paper on Manufacturing Industries” (Japanese)
- Project Design Online — commentary on the 2026 White Paper on Manufacturing Industries (Japanese, 2026-06-01)
- MONOist — coverage of the primeNumber “AI and Data Utilisation Survey 2026” (Japanese, 2026-07-21)
- Thailand Board of Investment (BOI) — Q1 2026 investment application announcement
