Most industrial AI projects don't fail because of bad algorithms. They fail because the data feeding those algorithms is inconsistent, incomplete, or quietly wrong.
Plant teams spend months evaluating vendors, building models, and setting up infrastructure. Then they connect to the historian and discover that years of operational data — data they assumed was reliable — is riddled with problems that make machine learning ineffective. The algorithm isn't the bottleneck. The data is.
Here's what actually goes wrong, and how to assess whether your plant data is ready for AI before you commit budget to a project that stalls in the data pipeline.
The 6 Data Quality Problems Hiding in Your Historian
1. Sensor Drift and Calibration Decay
Sensors degrade. A thermocouple that read accurately at commissioning may be off by several degrees after two years of thermal cycling. A pressure transmitter exposed to corrosive process fluid drifts slowly outside its calibration band.
The problem for AI: drift doesn't create obvious outliers. It introduces a slow, systematic bias that makes normal operating data look subtly different from what it actually was. Models trained on drifted data learn the wrong baseline. When you deploy them against freshly calibrated sensors, they throw false alarms.
2. Inconsistent Tag Naming Across Units and Sites
One unit calls it TT-101A. Another calls it TEMP_101_A. A third site has it labeled in the DCS as "Feed Pump Discharge Temp" with no structured tag at all. Every plant that has grown through expansions, acquisitions, or control system upgrades carries this legacy.
The problem for AI: any model that needs to generalize across units or sites — fleet-wide analytics, cross-plant benchmarking, transfer learning — depends on being able to programmatically map tags to equipment. Without a consistent naming convention, data engineers spend weeks on manual mapping before a single model gets trained.
3. Gaps from SCADA/DCS Polling Rates
Your DCS might scan at 1-second intervals, but the historian may only record on a 1-minute exception-based deadband. The data that reaches your analytics platform is already a lossy sample of what the process actually did.
The problem for AI: short-duration transients — the 15-second pressure spike during a valve transition, the 30-second temperature excursion during a feed change — vanish from the record. These are often exactly the events that precede equipment failures. If the historian never captured them, the model can't learn from them.
4. Timezone and Timestamp Mismatches
Plant A logs in UTC. Plant B logs in local time without daylight saving adjustments. The lab system timestamps in the local timezone of the server, which was configured in a different timezone during a migration three years ago. Maintenance records use the date the work order was closed, not when the work was performed.
The problem for AI: temporal alignment is everything in time-series analytics. If your vibration data, process data, and maintenance records are off by even an hour, the correlations your model finds are spurious. Multi-site models are especially vulnerable.
5. Missing Operational Context
The historian captures raw sensor values. It does not capture that the unit was in startup mode from 6:00 to 9:00 AM, that a heat exchanger was bypassed for cleaning, or that feed composition changed because a different crude grade arrived.
The problem for AI: a model sees a temperature drop and flags it as anomalous. In reality, it was a planned reduction during a mode change. Without operating mode context, the model cannot distinguish between a process upset and a normal operational transition. The result is a flood of false positives that erodes operator trust.
6. Historian Compression Artifacts
Most process historians use lossy compression — swinging door, boxcar, or similar algorithms — to reduce storage requirements. These algorithms discard data points that fall within a configured deadband, effectively smoothing the signal.
The problem for AI: compression removes exactly the kind of short-lived deviations and subtle pattern changes that anomaly detection models need. A compressor surge that lasted 4 seconds might be reduced to a single interpolated line segment. The historian technically has data for that period. It's just not the data that existed in reality.
Data Readiness Checklist
Before committing to an industrial AI project, run through these five questions honestly.
- Tag coverage — Do you have sensors on the assets you want to monitor? Predictive maintenance on a pump is impossible if you only have discharge pressure and no vibration, bearing temperature, or motor current data.
- Signal quality — What percentage of your critical tags have greater than 95% uptime over the last two years? Anything below that means your training data has significant gaps that will need imputation or exclusion.
- Naming consistency — Can a script map your historian tags to a standard equipment hierarchy (ISA-95, ISO 14224, or your own taxonomy) without manual intervention? If the answer is no, budget time and effort for tag rationalization before model development.
- Historical depth — Do you have enough examples of the failure modes you want to detect? If a compressor has failed twice in ten years and you only have three years of historian data, you may have zero failure examples to train on.
- Contextual metadata — Are operating modes, maintenance events, process changes, and equipment configurations logged in a structured, time-stamped format that can be joined to your sensor data? Spreadsheets and shift logs in PDF form do not count.
What To Do If You're Not Ready
Most plants are not fully ready. That is normal. The mistake is treating data readiness as a binary gate — either you're ready or you're not. The better approach is incremental.
- Start with your best-instrumented asset. Find the unit or equipment train that has the most complete sensor coverage, the cleanest tag naming, and the fewest historian gaps. Use it as your pilot. Prove value there, then expand.
- Fix tag naming in parallel. You don't need to rationalize every tag in the plant before starting. Map the tags for your pilot assets first. Build the naming convention and governance process as you go.
- Increase resolution where it matters. You may not need 1-second data on every tag, but identify the critical measurements for your use case and ensure they are being captured at sufficient resolution with appropriate deadbands.
- Start logging context now. Even if you can't backfill operating mode data for the past five years, begin structured logging today. In twelve months, you'll have a year of contextual data to pair with your sensor history.
- Quantify your gaps. Run a data quality audit: coverage, uptime, resolution, compression settings. Knowing the specific gaps lets you prioritize remediation and set realistic expectations for what AI can deliver with the data you have today.
Data Readiness Is a Competitive Advantage
Plants that invest in data quality before AI deployment don't just avoid failed projects. They build a foundation that makes every subsequent analytics initiative faster, cheaper, and more reliable. The unglamorous work of tag rationalization, historian configuration, and metadata governance compounds over time.
The plants that will lead in industrial AI adoption are not the ones with the biggest IT budgets. They are the ones that treated their operational data as an asset worth maintaining long before they tried to feed it to a model.