loader image

Home → Blog →

Indus­trial AI Doesn’t Start With AI

“too long,
didn’t read”

1

If your AI model can’t tell that “Motor_01,” “Drive A,” and “Asset 4711” are the same machine, it’s guessing, and it’s doing so with a confi­dence that can be genuinely misleading. Without a shared iden­ti­fier and shared seman­tics across systems, every reading arrives as an isolated string with no context attached. That is the actual bottle­neck for most Indus­trial AI pilots, not model quality.

2

A shared iden­ti­fier only creates value once your supplier, your machine builder, and your own MES all use the same one. Define your own internal stan­dard and you solve the problem exactly once, for your­self, then re-solve it for every new vendor. That is a coor­di­na­tion problem, and coor­di­na­tion prob­lems get solved by an alliance, not a project team.

3

Don’t try to map your entire company before starting. Pick one produc­tion line, one cell, or one machine type, not “the factory.” Teams that go narrow end up with some­thing real in 90 days. Teams that go broad end up with a trans­for­ma­tion program that never produces anything to point to.

So what do we
actu­ally start with?

Lucas Wolf, Tech­nical Content Manager @Open Industry 4.0 Alliance

August 8th

INDUS­TRIAL AI DOESN’T START WITH AI.

You’ve prob­ably had this feeling already. Everyone in the industry is talking about Indus­trial AI: new copi­lots, new predic­tive models, new autonomous agents, seem­ingly every other week. And some­where in the back of your head there’s a ques­tion you haven’t quite said out loud yet.

Where do we actu­ally start?

Here’s the thing nobody tells you at the confer­ence: it’s not with the AI. It’s with your data, and more specif­i­cally, with whether your data means the same thing to everyone who touches it.

That’s a frus­trating answer if you were hoping for a shortcut. But it’s also the honest one, and once you accept it, it’s kind of a relief. You don’t need to become an AI company overnight. You need to know what you’re working with, and you need it to be read­able by more than just you.

WHY DATA BEATS A GOOD MODEL.

Every plant is drowning in data. Machines, PLCs, MES, ERP systems, quality tools, sensors, engi­neering docu­men­ta­tion, all of it gener­ating infor­ma­tion constantly. The problem is almost never that there isn’t enough data.

The real problem is that it’s scat­tered, and every vendor names things their own way. Think about it from the model’s perspec­tive for a second. It has no idea that “Motor_01,” “Drive A,” and “Asset 4711” are the same phys­ical thing sitting on your shop floor. To the model, those are just three unre­lated strings. Without shared context, it isn’t reasoning, it’s guessing, and doing it with a confi­dence that can be genuinely misleading if you’re not careful.

This is exactly the problem OI4 members have already spent years working on together, so you don’t have to solve it alone, from scratch, inside your own IT depart­ment. Instead of every plant privately inventing its own way of saying “this reading belongs to this asset, under these condi­tions, with this main­te­nance history,” OI4 working groups have published reusable Asset Admin­is­tra­tion Shell submodel templates for this: a Master Asset Model to iden­tify what a thing actu­ally is, Condi­tion Moni­toring and OEE calcu­la­tion models to stan­dardize how health and perfor­mance data are struc­tured, and an Auto­matic Onboarding approach so a new asset can announce itself to the rest of the system instead of needing a custom inte­gra­tion project. Connect your data through that shared seman­tics, and the AI can spot real rela­tion­ships instead of staring at discon­nected numbers. That’s the differ­ence between a vendor who knows about AAS and an alliance that has already built and published the pieces.

STOP WAITING FOR PERFECT DATA.

Here’s a trap a lot of teams fall into: waiting for clean data before starting anything. It sounds respon­sible. In prac­tice it just delays every­thing indef­i­nitely. Perfectly clean data doesn’t exist, and it never will, no matter how long you wait.

The compa­nies that get some­where focus on some­thing more achiev­able: making data acces­sible, inter­op­er­able, and contin­u­ously better over time. Open stan­dards help because they let systems exchange infor­ma­tion without a custom inte­gra­tion project every time some­thing new gets added.

And here’s the part that’s easy to miss: this genuinely isn’t a problem one company can solve on its own, no matter how good its archi­tects are. A shared iden­ti­fier or a submodel only creates value once the machine builder who ships the asset, the soft­ware vendor who reads its data, and the plant that oper­ates it all use the same one. Define your own internal stan­dard, and you’ve solved the problem exactly once, for your­self, then you re-solve it for the next supplier, the next OEM, the next soft­ware swap. That’s not a data problem you can out-engi­neer inter­nally. It’s a coor­di­na­tion problem, and coor­di­na­tion prob­lems get solved by an alliance, not by a single project team. That’s the actual reason OI4 exists: not to sell you AAS as a product, but to be the room where suppliers, machine builders, and oper­a­tors agree on the same names for the same things, before you’re stuck building that bridge your­self, alone, one inte­gra­tion at a time.

THE PART THAT ACTU­ALLY MATTERS: YOUR FIRST 90 DAYS.

This is where most of the theory falls apart and reality kicks in, so let’s get concrete. You don’t need a trans­for­ma­tion program with a name and a logo. You need one good deci­sion, made delib­er­ately, over about three months.

DAYS 1 TO 30: FIGURE OUT WHAT YOU’RE ACTU­ALLY WORKING WITH

Don’t try to map your entire company. Go narrow and go real.

  • Pick one produc­tion line, one cell, or one machine type. Not “the factory.” One thing.
  • Ask the people who actu­ally run that line what breaks, what takes forever, or what they wish they knew earlier. Nobody ever asks them, and they usually know exactly where the pain is.
  • List every system that touches this line, PLC, MES, histo­rian, CMMS, and write down what each one calls the same asset. You’ll be surprised how often it’s three different names for one machine.
  • Find where data still moves by hand: an Excel sheet, a paper check­list, a screen­shot someone emails around. That’s usually your best oppor­tu­nity, because someone is already doing the work manu­ally and would love to stop.
  • End this phase with one sentence: “We want to solve X, for this line, because it currently costs us Y.” If you can’t write that sentence yet, stay here a little longer.

DAYS 31 TO 60: BUILD JUST ENOUGH STRUC­TURE

Unglam­orous, and nobody posts about it online. Skip it, and your pilot will look great in a demo and fall apart the moment someone changes a machine or adds a new sensor.

  • Give every asset in your use case one consis­tent iden­ti­fier, used every­where, from the PLC tag to the ticket in your main­te­nance system.
  • Decide on a minimal, real infor­ma­tion model for that use case. You don’t need to model your whole factory, just the ten or twenty data points that matter for this one problem. This is exactly where checking OI4’s existing submodel templates first can save you weeks: someone has likely already defined the fields for condi­tion moni­toring or asset iden­ti­fi­ca­tion that you’re about to rein­vent.
  • Check whether OPC UA, MQTT, or an Asset Admin­is­tra­tion Shell approach fits what you already have. Pick a stan­dard because it solves your specific connec­tion problem, not because it’s trendy.
  • Get IT and the process owner in the same room and agree on who owns what going forward. Saves you a very awkward conver­sa­tion in month four.
  • Build a simple dash­board, even a basic one, so people can see the data flowing before any AI touches it. If this step feels boring, that’s a good sign. It’s the part holding every­thing else together later.

DAYS 61 TO 90: BUILD ONE SMALL THING THAT ACTU­ALLY WORKS

Now, and only now, pick your AI use case. Keep it small enough to succeed in weeks, not quar­ters.

Good candi­dates: a main­te­nance assis­tant that answers ques­tions about a specific machine using its manuals and history, an anomaly detector for one well-under­stood failure mode, a search tool over engi­neering docu­ments for one product line, or a rule-based alert that flags out-of-spec condi­tions before they become down­time.

  • Define success before you start: fewer false alarms, faster time to detect a known fault, less time spent searching for docu­men­ta­tion. Pick a number you can check in 30 days.
  • Loop the output back into a real work­flow. An insight sitting in a dash­board nobody opens does nothing. Feed the alert into your CMMS or MES, wher­ever people already work.
  • Get the pilot in front of the people who’ll actu­ally use it early, not at the big reveal at the end.
  • Resist expanding scope halfway through. If someone says “while we’re at it, can we also,” write it down for phase two and keep going.

By day 90, you’re not trying to have trans­formed your company. You’re trying to have one thing that works, that people trust, and that you can point to when you ask for the resources to do the next one.

THIS IS A FOUN­DA­TION, NOT A FINISH LINE.

The model you use today will be outdated in a year, maybe less. That’s fine, that’s expected. What doesn’t become outdated is a data foun­da­tion that’s connected, contex­tu­al­ized, and built on stan­dards instead of one-off fixes.

Compa­nies that put in this ground­work aren’t just running one successful pilot. They’re setting them­selves up to adopt what­ever comes next, faster and with less pain, than compa­nies that start from scratch every time a new model shows up.

Indus­trial AI doesn’t begin with AI. It begins with knowing your data well enough that, when the AI finally shows up, it actu­ally has some­thing worth learning from.

If phase one of this already sounds familiar, the three names for one machine, the Excel sheet someone emails around, you don’t have to figure out days 31 to 90 on your own:

Look at what’s already built.
Browse the OI4 refer­ence archi­tec­ture and existing submodel templates, Master Asset Model, Condi­tion Moni­toring, Auto­matic Onboarding, and see how much of “days 31 to 60” is already done for you.

Bring your specific use case to an open OI4 working group call.
These sessions exist for exactly this conver­sa­tion: what’s your line, what’s the pain, which existing template already fits.

If it’s a fit, become a member
 and get access to the deeper tech­nical work: the full submodel library, the refer­ence imple­men­ta­tion, and the other oper­a­tors and vendors who are already three months ahead of you.

Join us!