In August 2026, Nordiska Projekt reported that 85% of Swedish industrial companies have not taken AI beyond the pilot stage.
Read that as a number about pilots rather than about AI. Getting to a pilot is not the hard part. Somebody found a use case, somebody found a budget line, somebody ran it, and then it stopped. Five out of six times, it stopped.
Something is happening between the pilot and the rollout, reliably enough to be a pattern rather than bad luck. It is worth asking what.
A project that cannot be finished
Ask most manufacturers what stands between the pilot and the rollout and you will get a version of the same answer: the data is not ready.
Ask what would make it ready, and the answer stops being specific.
That is the shape of the problem. "Fix your data first" is the most repeated piece of advice in industrial AI, and it is not a task. It has no definition of done, no owner who can declare it finished, and no test you could apply on a Tuesday to find out whether you have got there. Every honest attempt to scope it produces a bigger project than the one it was supposed to enable — a warehouse, then a taxonomy, then a cleanup of history that does not fit the new taxonomy.
A pilot is small enough to escape that. It runs on one line, on one dataset somebody cleaned by hand for the occasion. Rollout is where the unbounded project is waiting, which is exactly where the 85% are standing.
So the advice does not merely fail to help. It is a plausible reason the number is what it is: an organisation told to complete an infinite task before starting a finite one will do neither.
Nobody is refusing to do it
It is worth being clear that this is not a discipline problem, because it usually gets diagnosed as one.
Nearly every maintenance system built in the last two decades asks for the same thing as a job is closed: classify it. Which failure mode, which component, which cause. Leonard Lin, who manages Manufacturing Intelligence at Maintmaster, sums up what that produced in six words — "nobody does that; that's way too much effort."
Look at what it was asking for. Several seconds of taxonomy work, several hundred times a week, by someone whose shift has just ended, accurately, indefinitely, with no feedback ever reaching them about whether they got it right. No workforce complies with that, and none ever has. The requirement was unreasonable, and it was unreasonable in a way that was invisible from the office.
Which makes any plan whose first step is this time everyone fills the fields in properly the same plan that produced the data you already have.
There is a second half to that, and it runs the other way round. Leonard's explanation for why so little maintenance history is worth reading is not that people wrote it badly, but that nobody ever read it: a record no one consults is a record no one has had cause to write well. Quality follows use. It does not arrive ahead of it.
Put the two halves together and "fix your data first" is not merely unbounded, it is self-defeating. It prescribes a wait, and the wait is the mechanism. An organisation holding its records back until they are worth reading is running the process that keeps them from becoming worth reading.
What the pilot actually proved
Here is the part worth sitting with. A pilot that worked, on data you now describe as not ready, has already told you something: the data was good enough for that.
The reason it can be is that the requirement for structure has dropped. Free text is readable now. The classification does not have to be complete or consistent, because the analysis no longer depends on it to carry the meaning. That is a genuine change, and most of the market's advice was written before it.
What has not changed is that the event has to be recorded at all. That is a different bar from a clean one, and it is a much lower one — but it is not zero, and it is the bar worth checking against.
Which of your records clear it is a question with a real answer, and it takes an afternoon rather than a programme: what AI can forgive in your maintenance data, and what it can't is the test.
A bounded first step
The useful move at this point is not a bigger data project. It is a smaller one, with an end.
Whatever your pilot proved, it proved it on a defined slice of data. So define the next slice. One line, one asset class, one plant — a scope where you can say what "recorded" means and check whether it is true, rather than a programme whose success condition is the absence of a problem.
That is a decision an operations manager can make and finish. "Fix the data" is not, and after two years of not finishing it, the 85% is not surprising.
One thing that scope leaves open is how complete the slice has to be before reading it tells you anything, and the bar is lower than most teams assume. On Leonard's account you can begin on middle-good data. Say 50% of closures carry both the fault and what was done about it — or every one names the fault and none records the remedy. Nobody would defend either as a clean set, and in both the problems worth acting on are still visible, because problems worth acting on are the ones that repeat, and repetition survives a partial sample. What that buys is directional: which assets and which recurring failures deserve attention, not how large they are. For deciding where to look next, that is the entire requirement.
Which is the argument for reading early rather than late. Start mid-way and let what the reading exposes drive how the recording improves — the journey Manufacturing Intelligence exists to shorten, rather than a standard you have to reach before it is any use to you.
Bounding it is mostly a matter of writing down three things before you start, none of which requires a platform decision:
- Where. One line, one asset class, one site. Not "maintenance".
- What counts as recorded. A sentence you could hand to a technician and a supervisor and have them agree on. If you cannot write it, the scope is still too large.
- When you will look. A date, in the diary, at which you read a sample and see whether the answer changed. Not a milestone — a reading.
The third one is the one that gets dropped, and it is the one that turns this into a project with an end. Without it there is no moment at which anyone can say the thing worked, so the scope quietly grows to fill the absence — which is the same failure as "fix your data first", just at a smaller scale.
None of that is an AI decision. It is the ordinary discipline of scoping a change on a shop floor, applied to recording rather than to a machine. The reason it is worth spelling out is that the AI framing tends to suspend it: teams who would never approve an unbounded maintenance project will approve an unbounded data one, because the data one sounds like preparation rather than work.
If the honest answer to is the event captured in a system at the time it happens? is no — if it is a shift book, a spreadsheet, or a conversation — then that is the bounded project, and it is smaller than the one you were about to scope. Maintmaster CMMS is one place to record what happened and what was done about it, at the point of work, which is the input every later analysis depends on.
Start there. It has an end, which is the whole difference.