Do we need a paid AI platform subscription, or can we start with what our PLC vendor offers?

Start with what your PLC, SCADA, or CMMS vendor already offers. Rockwell, Siemens, GE Digital, and most major MES platforms now ship a basic predictive module that reads tag data you already collect. The free or bundled tier is usually enough for a single-line pilot. The paid AI platforms (Augury, Uptake, Senseye, AspenTech) earn their keep when you scale past three or four lines and need cross-asset pattern detection. Buy the bundled tool first, prove the model, then evaluate the dedicated platforms with real numbers from your pilot. Most plants that buy the dedicated platform first end up with a tool nobody uses because the integration work was underestimated.

Is consumer AI like ChatGPT or Claude safe for our process data and equipment specs?

Not for the actual sensor streams or proprietary process specs. The consumer tiers retain prompt data and use it for model improvement under their default terms. Use them for general work like drafting your pilot scope document, summarizing vendor pitches, or writing internal training material. For the live sensor data, the equipment runbooks, and anything that would tell a competitor how you make your product, stay inside the vendor platform that has a signed Data Processing Addendum or your on-prem MES. If your IT director negotiates an enterprise agreement with Anthropic, OpenAI, or Microsoft Copilot, the rules change and the IT team will tell you what is in scope.

Will the pilot output sound like every other vendor case study, or will it tell us something specific to our plant?

Only if you scope it that way. The case studies you see in vendor decks are written for the vendor's marketing team. Your pilot output should answer three plant-specific questions: did MTBF improve on the pilot asset compared to the prior 12 months, did MTTR drop because we caught the failure earlier, and did the model produce false positives that wasted maintenance hours. Build the report template before the pilot starts. Decide what numbers count. If your vendor cannot map their output to your existing CMMS work-order categories, that is a sign the pilot will not produce numbers your CFO trusts.

How do we share results with leadership when our COO does not have access to the AI platform?

Export. Every credible vendor produces a PDF or Excel summary you can email or drop into SharePoint. The COO does not need a login. What the COO needs is a one-page summary that shows the baseline MTBF and MTTR for the pilot asset over the prior 12 months, the same numbers during the pilot window, the alert log with what was caught and what was missed, and a dollar-value estimate of the avoided downtime. Build the one-pager during week one of the pilot, not in week 12. If you wait until the end, the data conversation becomes a slide-design conversation and the project loses momentum.

What if our IT department blocks the cloud platform the vendor wants to use?

Three paths. One, ask the vendor for an on-premises or private-cloud deployment. Most enterprise predictive maintenance vendors offer it, though pricing is higher and deployment is slower. Two, run the pilot in an air-gapped environment with sample data exported manually for the first 90 days. Slow, but it gets you to a number. Three, escalate to the CIO with a specific use case scoped to one asset, one line, and a defined data flow. IT departments rarely block AI in absolute terms. They block undefined scope. A scoped one-line pilot with a clear data inventory usually clears review in two to four weeks.

Can our maintenance technicians use the AI platform on the floor, or is this a desk-only tool?

Floor use is the point. The maintenance team is who needs to act on the alerts. Most modern predictive platforms have a mobile app or tablet view that surfaces the asset health score, the open alerts, and the recommended action. Plan the floor rollout in week six or seven of the pilot, not at the end. If you wait, the technicians do not trust the tool and the alerts get ignored. Run a 30-minute floor session where two senior techs walk through the alert log, validate the calls, and tell you whether the model agreed with their gut. That session is the most important hour of the pilot.

I am the plant manager, not an engineer. Is this realistic for me to run?

Yes. The plant manager is actually the right owner for a predictive maintenance pilot, because the success criteria are operational, not technical. You need a maintenance lead who knows the asset, an IT contact who handles the data flow, and a vendor who is willing to scope to one line. The technical work happens inside the vendor platform. Your job is to define the success metrics, hold the weekly check-in, and decide at week 12 whether the pilot earned Phase 2 budget. The plants where the pilot fails are usually the ones where the maintenance lead owns it without an operational sponsor.

What if our equipment is too old to have the right sensors?

This is the most common pilot blocker and the most fixable. You do not need full sensor coverage on every bearing and motor. You need enough signal to detect the failure mode you care about. For most rotating equipment, that means vibration and temperature, both of which can be retrofitted with wireless sensors in under an hour per asset for $200 to $800 per sensor depending on the platform. Pick the asset where one or two new sensors fills the gap, not the one that needs ten. If the gap is bigger than that, the pilot is not ready and you would burn 90 days on a model trained on insufficient data.

How Do Mid-Market Plants Run an AI Predictive Maintenance Pilot Without a Data Science Team?

Most plants I walk into have the same maintenance story. A critical asset went down at 2 a.m. on a Saturday, the on-call tech rolled in by 4, and the line was back up by Monday afternoon. Two days of lost throughput, a customer call you would rather not have made, a maintenance budget already running over. The post-mortem turned up vibration data nobody was reading, a temperature trend that drifted three weeks before the failure, and a CMMS work order from six months ago flagging the same bearing for replacement.

This is the pattern. The data exists. Nobody has the time to read it. Predictive maintenance AI is the cleanest commercial answer to that problem in the mid-market. Done well, it pays back in one avoided unplanned shutdown.

Most plant managers I talk to know they should be running a pilot. The reason they are not is that every vendor pitch starts with "you will need a data science team," and the plant does not have one. So the project gets quoted at $400k for a 24-month rollout that touches twelve assets, the COO gets the deck, and the project dies on the procurement memo.

Here is the pilot path that actually works at $20M to $500M plants. One line. Ninety days. A real number for the CFO at the end. No data scientist required.

Why this matters for mid-market manufacturers specifically

The mid-market plant has the worst predictive maintenance economics of any segment. Big OEMs and Fortune 500 manufacturers can afford a corporate reliability team and a multi-year Industry 4.0 program. Small fabricators run on the maintenance lead's experience and a wall calendar. Your plant sits in between. The asset base is too valuable to run reactively. The capex budget is too tight to fund a 24-month corporate rollout. The maintenance team is good but stretched.

This is the segment where AI predictive maintenance moves the OEE needle most, because there is real money tied up in unplanned downtime and a real ceiling on the maintenance staff you can hire. A pilot that proves you can predict three failures across one critical line and cut MTTR by 30 percent earns the Phase 2 budget and gives the plant a tool the maintenance lead actually wants to use. Skip the pilot, and the plant either over-buys (the 12-asset corporate rollout that nobody runs) or under-buys (a sensor kit on the shelf and no analyst to read it).

What AI predictive maintenance actually does

AI predictive maintenance reads the sensor data your equipment already produces (vibration, temperature, current draw, pressure, acoustic emissions) and flags the patterns that precede failure. The model learns what "healthy" looks like for your specific asset, then surfaces deviations early enough to schedule the repair before the asset fails on shift.

Three things make it different from the condition monitoring tools your plant probably already has on the shelf:

It learns your asset, not a generic asset class. A condition monitoring threshold tells you "vibration over 0.3 in/sec is bad." An AI model tells you "this specific motor's vibration has shifted from its 90-day baseline by an amount that historically correlated with bearing failure within 14 days."
It correlates across signals. The model spots that vibration plus temperature plus current draw together signal a failure pattern, even when none of the individual signals breach a threshold.
It improves with data. The first 60 days of any pilot are about establishing baselines. The second 60 are about catching real failures. By month six, the model is calling failures the maintenance lead used to spot only after they happened.

Think of it as the corporate reliability team you cannot afford, running 24-7, on the asset that costs you the most when it goes down.

Before you start

You need:

One critical asset on one line. Not three. One. The asset where unplanned downtime costs the most per hour.
12 months of historical data on that asset (work orders, downtime events, repair costs). Pull it from the CMMS now, before the pilot starts.
A maintenance lead who knows the asset, an IT contact who can authorize the data flow, and a vendor willing to scope to one asset.
About 40 hours of internal time across the 90 days, mostly the maintenance lead's. Plus a weekly 30-minute check-in.
A budget envelope of $15k to $40k for the pilot itself, depending on whether you need to add sensors.

One thing to settle before any vendor sees a single tag of your data: the IP and worker privacy rule. We have a dedicated section on this below. It is non-negotiable. The five minutes you save by sending a vendor a tag dump without scoping the data can become a year of cleanup if the data ends up training a model your competitor uses.

Step 1: Pick the right asset

The pilot fails or succeeds at this step. Most plants pick the wrong asset and burn 90 days on a model that has nothing to learn.

The failure pattern: someone picks the asset everyone hates (the old extruder, the cranky press, the conveyor that never runs right). It is a tempting choice because you would love to fix it. It is the wrong choice because the asset's failure pattern is so erratic that no model can learn from it in 90 days.

What to ask your maintenance lead and the operations team instead:

Which asset on the plant floor meets all of these criteria: it has had at least three documented unplanned failures in the past 18 months, the failures share a probable failure mode (bearing, gearbox, motor, pump, valve), it has at least basic sensor coverage already (vibration or temperature), unplanned downtime on it costs us at least $5,000 per hour in lost throughput or scrap, and the maintenance team agrees the failures should have been catchable with better data.

The prompt forces the team to stop arguing about which asset "deserves" attention and start identifying the asset that gives the model something to learn. You want repeating, mechanical, sensor-visible failures. Bearing wear on a critical pump. Motor degradation on the main drive. Gearbox issues on a primary conveyor. Avoid assets where the failure mode is electrical (control system) or operational (operator-induced). Those need different tools.

For a packaging plant, this is usually the case packer drive or the labeler servo. For a metals plant, the rolling mill main bearing. For food and beverage, the homogenizer or the cooling tower fan. For chemicals, the agitator drive or the pump on the critical transfer line. Pick the asset, write down the cost-per-hour of unplanned downtime, and you have your business case anchor.

Step 2: Pull the historical baseline

The second-most-skipped step in predictive pilots is the baseline pull. Without it, you cannot prove the pilot worked. The CFO asks "what was MTBF and MTTR on this asset before AI," and you do not have a number, and the project dies in the budget review.

What to pull from the CMMS, ideally for the last 24 months:

For asset [tag/ID], list every work order from the past 24 months: open date, close date, work type (preventive, corrective, emergency), parts used, labor hours, and downtime hours. Calculate MTBF (mean time between failures, counting only corrective and emergency work orders), MTTR (mean time to repair, downtime hours per failure event), total scrap or throughput loss attributed to those events, and total maintenance spend on the asset.

This becomes your before number. If your CMMS is SAP PM, Maximo, eMaint, Fiix, UpKeep, or even an Excel-based tracker, the data is in there. The pull takes one to three hours of the maintenance planner's time. Do it before the vendor signs a contract. Some plants discover at this step that the CMMS data is dirty enough that the pilot needs a different asset. Better to find that out in week zero than in week 12.

For plants without a real CMMS, the operator log book and the production downtime tracker get you most of the way there. Just pick consistent definitions. "Failure" means line stopped, called for maintenance. "Repair time" means tool-down to tool-up. Document the definitions in the pilot scope so the after-numbers are apples to apples.

Step 3: Scope the data flow with IT and the vendor

This is where most pilots stall. The vendor wants tag access. IT wants to know what data leaves the network. The maintenance team wants the alerts. Three weeks pass and nothing has been connected.

The scope conversation, written down, prevents that:

For the pilot on asset [name], the data flow is: sensor tags [list] are read by the existing PLC or SCADA, exported via [OPC UA / MQTT / CSV / vendor connector] to the vendor platform [name], analyzed in the vendor's [cloud / on-prem] environment, and surfaced as alerts in [dashboard / mobile / email]. Data sent off-site includes only the listed tags. No work order detail, no operator names, no proprietary recipe or process spec, no quality data tied to specific lots. Vendor signs a Data Processing Addendum, agrees to data deletion at pilot end if we do not proceed, and confirms in writing that pilot data will not train cross-customer models.

Write this scope. Send it to IT and the vendor before the contract. Most legitimate vendors will sign it without pushback. The ones that hesitate are telling you something. The plants that skip this step end up with their proprietary process data sitting in a vendor's training set, which is a one-way decision you cannot reverse.

For plants with a strict data exit policy, ask the vendor for an on-premises deployment. Augury, Senseye, AspenTech, and most of the established vendors offer it. The cost is higher and the setup is longer, but the data never leaves your network. For a single-line pilot, a hybrid model where sensor data flows out and only model outputs flow back works for most IT teams.

Step 4: Run the model and capture alerts

The first 30 days of the model running, expect noise. The model is learning your asset's normal pattern and will throw alerts that are not real. This is expected. Most pilots fail here because the maintenance team gets fatigued by false positives in week two and stops checking the alerts.

What to ask the vendor for in week one:

Please provide a tuning protocol for the first 30 days. We will treat alerts as advisory only during this window, log every alert with the maintenance team's call (real failure pattern, false positive, ambiguous), and review the log weekly with you to retune the thresholds. We expect the alert volume to drop by 50 percent or more between week one and week four. If it does not, the pilot needs an intervention.

The weekly tuning call is the most important hour of the pilot. The maintenance lead, the vendor's solutions engineer, and the operations sponsor walk through every alert from the prior week. The maintenance lead grades each alert. The vendor adjusts thresholds. By week six, the alert volume should be down to one or two per week, mostly real signal.

This is also where the maintenance team starts trusting the tool. The first time the model calls a bearing degradation 10 days before the failure would have happened, and the team replaces the bearing on a planned shutdown for $400 instead of an emergency response for $40,000, the conversation about Phase 2 changes.

Step 5: Build the 90-day report and the Phase 2 ask

The pilot ends with a one-page report or it ends with nothing. The plants that produce a real report get Phase 2 funded. The plants that try to extend the pilot informally lose the budget conversation.

The report template you build in week one and fill in week 12:

90-Day AI Predictive Maintenance Pilot Report. Asset: [name]. Pilot window: [start date] to [end date]. Baseline (prior 12 months): MTBF [X hours], MTTR [Y hours], unplanned downtime [Z hours], cost of unplanned downtime [$ figure]. Pilot results: MTBF [X hours], MTTR [Y hours], unplanned downtime [Z hours], avoided cost [$ figure], number of true positive alerts [count], number of false positives [count], number of failures missed [count]. Phase 2 recommendation: [continue with same vendor, expand to lines X and Y / change vendor / pause]. Estimated Phase 2 cost: [$ figure]. Estimated Phase 2 payback: [months].

The report fits on one page. The COO reads it in 90 seconds. The CFO reads the cost and payback line and approves or rejects. The plants that produce this report and pitch a 12-month Phase 2 expansion at three to five times the pilot cost get funded almost every time, because the pilot already produced a real number.

The plant-specific prompts that actually work

After watching plants run a couple of dozen of these pilots, the difference between a pilot that produces real numbers and one that produces vendor case-study fluff comes down to four prompt moves you make with your vendor and your internal team.

Specify the asset and the failure mode, not just the line. "We want predictive maintenance on the packaging line" is a vendor pitch trigger. "We want to predict bearing wear on the case packer drive motor on Line 3, which has had four documented bearing failures in 18 months" is a scope. The first gets you a vendor proposal for the line. The second gets you a pilot that has something to learn.

Specify the constraint that actually matters. Cost per hour of unplanned downtime, MTBF target, false positive tolerance, and time to alert. Pick the constraint that, if the vendor got it wrong, would make the pilot useless. For most plants the binding constraint is false positive tolerance. If the model cries wolf three times a week, the maintenance team stops listening. Tell the vendor up front that false positive tolerance is the success metric.

Specify the integration before the algorithm. "Will this read from our Rockwell PLC and write to our Maximo CMMS" matters more than "what model architecture do you use." The plants that get the algorithm conversation right and the integration conversation wrong end up with a model nobody acts on. Reverse the priority. The pilot fails on integration before it fails on accuracy.

Specify what stays inside MES and ERP regardless. Recipe data, supplier contracts, customer-specific quality tolerances, BOM data with margins, and anything tied to a worker by name stays inside SAP, Oracle, NetSuite, or your MES. The vendor reads sensor tags. Nothing else. Make this explicit in the data flow document. The vendors who balk are the ones you do not want.

The OSHA, worker privacy, and IP non-negotiables

This section is short because the rule is simple, but it is the most important section in this guide.

Do not put any of the following into the consumer tier of an AI tool or into any vendor environment that has not signed a Data Processing Addendum:

Proprietary process specifications, recipes, or formulations
Supplier contracts, BOM data with margins, or pricing terms
Worker names, badge IDs, shift schedules, or any data that ties a sensor reading to a specific person
Safety incident reports, near-miss data, or OSHA recordable details
Customer-specific quality tolerances or contract terms
CCTV footage from the floor, especially if it identifies workers
Photos of the production line that reveal trade secrets in the background

Worker privacy is the most-overlooked piece. If your line has cameras for vision quality inspection (covered in another guide in this series), or wearable sensors on technicians, or RFID badges that log who was on what asset when, that data ties a sensor signal to a person. That puts it under your worker privacy policy and, in some states, under union agreements. Do not pump it into a third-party AI platform without HR and legal review.

The practical workflow that respects the rule: build pilot scoping documents, vendor evaluation criteria, and internal training material in AI tools. Run the predictive model on sensor tags only, inside a vendor environment with a signed DPA, with explicit data deletion terms at pilot end. Anything tied to a worker, a supplier contract, or a process recipe stays inside MES (Wonderware, Rockwell FactoryTalk, Siemens Opcenter), ERP (SAP, Oracle, NetSuite), or your CMMS regardless of how convenient the AI platform is.

If your company has signed an enterprise agreement with the AI vendor that includes a Data Processing Addendum, the rules can be different. Ask your IT director or general counsel what is covered. Do not assume.

When NOT to use AI predictive maintenance

Predictive maintenance AI is the right tool for some assets and the wrong tool for others. The vendors will pitch it for everything. Push back.

Skip it for:

Anything safety-critical without expert review. If the asset is under PSM (Process Safety Management) for highly hazardous chemicals, or if its failure mode involves pressure vessels, boilers, or anything that could injure a worker, the AI alert is advisory at best. Have a certified reliability engineer or process safety lead validate the model output before it changes a maintenance schedule.
Assets with no consistent failure history. A pump that has failed once in 10 years is not a pilot candidate. The model has nothing to learn from. Stick with traditional preventive maintenance and time-based replacement on those assets.
Electrical and control system failures. Most predictive AI works on rotating equipment with mechanical wear patterns. Control failures, PLC issues, and electrical faults are different beasts. Use the diagnostic tools your control vendor provides instead.
Operator-induced failures. If the asset fails because of how the line is being run, not how the asset is wearing, AI predictive maintenance will not help. The fix is operator training and process control, not a model.

A simple rule: AI predictive maintenance is an unfair advantage on the 80 percent of mechanical assets where wear patterns produce sensor signal. Trust the official channels and the experienced maintenance lead for the 20 percent where the failure has safety, electrical, or operational weight.

The quick-start template

Here is the pilot scope scaffold. Copy it, fill in the brackets, send it to the vendor as your first written request before any contract gets drafted.

90-Day AI Predictive Maintenance Pilot Scope.

Asset: [name and tag ID]. Plant: [location]. Line: [name].

Failure mode of interest: [bearing wear, motor degradation, gearbox, pump, etc.].

Existing sensor coverage: [vibration / temperature / current / pressure, with sample rate].

Sensors to add (if any): [list, with budget].

Data flow: from [PLC/SCADA] via [OPC UA / MQTT / CSV] to [vendor platform], hosted [cloud / on-prem]. No process recipes, supplier data, worker data, or quality data leaves the network.

Baseline metrics (prior 12 months): MTBF [hours], MTTR [hours], unplanned downtime cost [$/hour].

Success metrics for pilot: MTBF improvement [target], MTTR improvement [target], avoided cost [target], false positive tolerance [target].

Vendor commitments: weekly tuning call for first 6 weeks, monthly review thereafter, one-page report at week 12, data deletion at pilot end if we do not proceed, written confirmation that pilot data will not train cross-customer models.

Pilot budget: [$ envelope]. Internal owner: [maintenance lead name]. Operational sponsor: [plant manager name].

That is the whole pattern. For most mid-market predictive maintenance pilots, this is enough.

For recurring pilot scoping (when you expand to a second line in Phase 2 or test a different vendor on a different asset), reuse this template and update the asset, sensor list, and metrics. The structure stays. Only the specifics change.

Bigger wins beyond the first pilot

Once the first pilot produces a real number and earns Phase 2 budget, the next layer of value shows up in places that go past one asset.

Pilot library across the plant. Run two or three more single-asset pilots in parallel during Phase 2, on different failure modes. A bearing-wear pilot on a pump, a motor-degradation pilot on a drive, a gearbox pilot on a conveyor. Each one teaches the maintenance team something about how the model works on different assets. By the end of Phase 2 you have a vendor selection backed by real plant data, not vendor case studies.

CMMS integration that closes the loop. The pilot starts as alert-only. Phase 2 connects the model output back into the CMMS so an alert auto-generates a work order with the recommended action. This is where the time savings really show up. Maintenance planners stop manually translating alerts into work orders. The model's recommendation flows directly into the planner queue.

OEE integration that ties maintenance to production. Once you have predictive working on the critical assets, the next step is connecting maintenance health scores to the OEE dashboard. The plant manager sees throughput, quality, availability, and an asset health score that predicts the next 30 days of availability. This is where the conversation shifts from maintenance cost to production capacity, and where the COO starts asking different questions.

Vendor consolidation. Most mid-market plants end up with three or four predictive tools running at once (a bundled module from the PLC vendor, a pilot from a dedicated AI vendor, a condition monitoring tool from a sensor company, a corporate analytics layer). Phase 3 is consolidating to one or two. The pilot data tells you which vendor actually performed. Use it.

The manufacturing AI consulting connection

This is one tool in one category. Plants that figure out the broader manufacturing AI question, where it fits and where it does not, end up with a maintenance program that runs cleaner, an OEE number that tells the truth, and a capex stack that earns its budget. Plants that keep buying point solutions usually end up with a tool stack that nobody uses and a corporate Industry 4.0 initiative that everyone has stopped trusting.

If your plant or company is wrestling with the bigger AI question, the AI Consulting in Manufacturing page covers the full scope: where AI actually fits in mid-market plants, what the common failure modes look like (the 12-asset corporate rollout, the data lake that nobody queries, the vision system that gets unplugged), and what an engagement looks like when it works.

For plant managers and COOs, start with this guide. Run one pilot on one asset over 90 days. Build the one-page report. Take it to the COO. The conversation about Phase 2 budget is a different conversation when there is a real number on the table.

Closing

The goal is not to turn the plant into a Silicon Valley showcase. It is to catch the bearing failure on Saturday morning before it happens, schedule the repair on Tuesday's planned shutdown, and stop having the conversation about why the line went down again. AI predictive maintenance is the closest tool I have seen to that goal for mid-market plants specifically. It rewards focused scoping, respects the realities of your maintenance team, and earns its budget on the first avoided shutdown.

Pick one asset this week. Pull the 12-month history this month. Get the vendor scope written by next quarter. The pilot pays back before the corporate Industry 4.0 plan has its kickoff meeting.

If you want to talk about how AI fits into your plant or company at the program level, the AI Consulting in Manufacturing page lays out the full picture and how an engagement works.