Software and dataPillar article
Should you build your AI, buy it, or repurpose a consumer tool?
Build, buy or repurpose a consumer tool: the three routes to AI on the factory floor, the criteria that actually decide, and where to start.
The request often comes from the top, in a form that helps no one: "we need AI."
Whoever picks up the topic opens the market. They find dozens of platforms promising the same thing in the same words, a demo that dazzles in the meeting room, and no way to tell which one will hold once wired to their own data.
The real starting point is not the list of platforms. It is knowing which precise problem you want to solve, and which of the three routes to AI answers it.
The essentials
There is no single "AI platform" you just need to pick well. There are three routes: build custom, buy specialised software, or repurpose a consumer tool. The choice does not hinge on advertised features, but on three questions about you: what state your data is in, where it is allowed to go, and who will keep the tool alive once the vendor has left. A brilliant solution sitting on messy data produces nothing.
Build, buy or repurpose: which route for which need?
Behind the noise of the market, there are only three ways to bring AI into a factory. Naming them already sorts out half the offers.
| Route | In a word | What it brings | The risk to watch | When to choose it |
|---|---|---|---|---|
| Build | Custom | Fits your process closely | Dies without an owner to maintain it | When nothing exists for your need |
| Buy | Off-the-shelf | Proven solution, support, updates | Vendor lock-in, reversibility | When a vendor in your field already solved it |
| Repurpose | Consumer tool | Fast, nearly free | Data leakage, no guarantee | For low-stakes tasks, once usage is framed |
Table scrolls horizontally on small screens.
Build custom
Have a solution developed for your process, alone or with a contractor. It is the route that fits your reality best, and the most demanding.
It assumes clean data, a specification held to, and above all someone to maintain the tool afterwards. Many custom projects die not at delivery, but six months later, for lack of having planned who would keep them alive.
Buy specialised software
A vendor in your field has already solved your problem for other sites. You buy a proven solution, support and updates.
The price: an imperfect fit to your specifics and a dependence on the vendor. Check the point nobody looks at when buying: how you get your data back the day you leave.
Repurpose a consumer tool
Your teams already use, sometimes without saying so, a general-purpose AI to summarise a document or draft a report. It is the fastest and cheapest route.
It is also the riskiest if left unframed: pasting a confidential report into a public tool sends it out of the company. This is covered in detail in data leaks and shadow AI.
Best practice: combine the routes
Mature sites do not pick a single route. They repurpose a consumer tool for low-stakes tasks, buy specialised software for their core business, and build custom only where nothing exists. The mistake is not choosing the wrong route: it is using the same one for everything.
What does an "AI platform" really cover?
The word "platform" lends solidity to very different things. It needs unpacking, because that is where expectations break. An offer usually mixes three layers:
- A wrapper over an existing large language model. The intelligence comes from elsewhere; you pay for the packaging, integration and support. Not a flaw, as long as you know it.
- Real, specific work: reading technical documents, extracting measurements, searching a history, classifying defects. This is where the value is, and what you should have demonstrated on your documents.
- What no platform does: decide on fitness for service, requalify, sign, carry the liability.
That last boundary is the same for all: the tool proposes, the human validates. It is developed in human validation of industrial AI.
A solution that claims to remove it does not save you time. It transfers you a risk.
Which criteria actually make the difference?
Comparisons rate solutions on dozens of rows. In practice, five questions decide, and they are about your situation, not the product.
What state is your data in?
The criterion nobody wants to look at first, and the only one that decides everything. An AI feeds on what you already have: reports, histories, equipment tags.
If that data is scattered across PDFs, poorly tagged, incomplete, no solution will compensate. Choosing a platform before looking at your data is buying a car without checking you have a road.
Where is your data allowed to go?
Cloud hosting or processing on your own servers is not a technical preference; it is sometimes an eliminating criterion.
In food and pharmaceutical plants, the real state of the installations is sensitive information that some managements refuse to let leave the site. The question is settled at the start of the project, not the end. The topic is covered in local AI, off the cloud.
What will the solution need to talk to?
An isolated AI becomes one more data-entry chore. A useful AI exchanges with what already exists: the CMMS, the ERP, the control system.
The right question is not "does it offer connectors", but "which flows will I actually wire in, and which will I keep re-keying by hand".
Who will keep it alive internally?
A solution deployed by a contractor and handed to no one dies slowly. You need an owner: someone the problem directly concerns, trained to run the tool and judge its results.
Without that relay, the best deployment fades in six months. What this skill-building really involves is described in training a maintenance team in AI.
What will you get back when you leave?
Reversibility is checked before signing, never after. A solution you cannot extract your data, histories and settings from holds you captive, whatever its price.
Ask explicitly how you get out, and in what format.
When the demo holds and the tool falls
A food plant wanted to finally exploit its inspection reports, scattered across PDFs between two contractors. A platform gives a convincing demo to the management: drop a report, watch the measurements appear, query the history in plain language. The project is launched on the spot.
It did not fail on the technology. It failed because the real reports did not look like the demo ones: equipment tags changing from one contractor to the next, poor-quality scans, heterogeneous formats.
The tool read a clean report well and got lost on the real asset base. No one internally had time to redo the tags. The data needed for the AI to be useful was never built.
The problem was not the platform. It was choosing the tool before looking at the state of the data.
General-purpose or specialised tool: which for which task?
This is where projects go wrong most, because the two families look alike in a demo.
| Criterion | General-purpose tool | Specialised tool |
|---|---|---|
| Domain knowledge | None | Vocabulary, formats, standards |
| Flexibility | Very versatile | Focused on one domain |
| Cost | Low | Higher |
| Facing errors | Wrong with full confidence | Wrong less often where it matters |
| Good for | Drafts, summaries, translation | Extracting measurements, preparing a technical decision |
Table scrolls horizontally on small screens.
The split is not "which is better", but "for which task":
- Drafting a report: the general-purpose tool is enough.
- Extracting measurements from an inspection report to feed a history that fitness-for-service decisions depend on: the specialised tool, with human validation.
Handing a decision that carries consequences to a general-purpose tool because it dazzled in a demo is the most frequent and the most expensive mistake.
Why does deployment matter as much as the choice?
A well-chosen, badly-deployed solution fails like a bad one. The schedule matters as much as the comparison.
The rule that holds: start small. A narrow scope, a single use case you can judge.
An all-at-once rollout almost always fails, for two reasons:
- It asks the whole organisation to change habits on the same day.
- It leaves no room for learning.
A first case that works pulls the rest along far better than an imposed master plan. How to frame that first scope is detailed in the first AI project in 90 days.
That caution shapes the choice: prefer a solution that lets you start on a small scope without committing the whole site. And before launching, do the calculation that is almost always missing, the real return, with the business case of an AI project.
How to choose, concretely, in five steps?
Name the problem before looking at tools
Not "we need AI", but a precise task you want to stop doing by hand: re-keying reports, finding a history, preparing an audit. That defines the route, not the vendor brochure.
Look at the state of your data before comparing
A solution is only worth the data you give it. If the data is not there, the first project is not AI, it is the data.
Settle hosting at the very start
Is your data allowed to leave the site? That single question eliminates part of the offers up front, and stops you falling for a tool a management will refuse at the end.
Have it demonstrated on your documents, not on the demo
Insist on a trial with your real reports, with their defects, formats and heterogeneous tags. That is where most solutions reveal their limit.
Start on a narrow scope and check the exit
One use case, one workshop, and reversibility settled before signing. A rollout that works small scales up; an all-at-once rollout that fails takes the whole project with it.
- Choosing the tool before looking at your data.The mother mistake, the one that contains all the others. A brilliant platform on messy data produces nothing.
- Using the same route for everything.General-purpose for low-stakes tasks, specialised for the core business, custom where nothing exists.
- Deciding on the demo.A demo is built to convince, on ideal data. What matters is behaviour on your real documents.
- Forgetting who will keep the tool alive.Without an internal owner, the best solution fades in months.
- Handing a consequential decision to a general-purpose tool.It states an error with the same confidence as a right answer.
- Neglecting reversibility.A solution you cannot extract your data from is a trap, whatever its price.
Should you build your own AI or buy one?
It depends on the problem. Buy specialised software when a vendor in your field has already solved your need; build custom only where nothing exists and where you can maintain the tool afterwards. Custom fits your reality better but dies without someone to keep it alive.
Can you use a general-purpose AI like ChatGPT in a factory?
For low-stakes tasks (drafting, summarising), yes, provided usage is framed. The risk is not the tool but what you put in it: a confidential report pasted into a public service leaves the company. Never hand it a technical decision without human validation.
How do you compare industrial AI platforms?
Not on the feature list, which all look alike. On five points about you: the state of your data, where it is allowed to go, what the tool must connect to, who will keep it alive internally, and what you can get back on leaving. And by having it demonstrated on your real documents.
Where do you start an AI project in a factory?
With the precise problem to solve, then the state of your data. If the data is not ready, the first project is the data, not AI. Only then comes the choice of solution, on a narrow scope before any wide rollout.
Is a custom AI solution more reliable than off-the-shelf software?
Not by nature. Custom fits your process better, but it depends entirely on the quality of what was built and the upkeep that follows. Specialised software proven on other sites is often safer, at the cost of an imperfect fit. Reliability rests less on the route than on the data and the follow-up.
Written by Adama CamaraAI Consultant · Industry · view profile
Published on August 4, 2026
Software and data
Industrial AI: What It Really Is, and What It Changes on the Plant Floor
Industrial AI without the jargon: use cases by function and by sector, limits, costs, financing and a roadmap to get started in your plant.
AI and maintenance
Delivering a first AI project in maintenance: a 90-day roadmap
How to run a first AI project in industrial maintenance without spreading yourself thin: the scope to pick, the first 90 days, and the traps that sink it.
AI and maintenance
Local AI off the cloud: deploying an LLM or LMM on site
Why deploy AI on-premise rather than in the cloud: what an LLM or LMM does on an industrial site, the tasks it automates and the real constraints.
AI and maintenance
Making the case for an AI maintenance project to your board
How to cost an AI maintenance project so it survives the boardroom: what you measure, what you own as an assumption, and what you must never promise.