The 70% Problem: Why AI in Asset Management Gets Stuck Before It Starts

There is a number that anyone who has run an AI project in an asset-intensive industry will recognize: 70%. That is the share of machine learning effort that typically goes to data preparation, extraction, and validation — not to building models or deriving insights, but to cleaning, reconciling, and normalizing the raw material those models need to function.

The utilities that have successfully deployed AI-driven maintenance intelligence — Duke Energy, National Grid, PG&E among them — reached that point by investing in data integration before selecting AI use cases. They treated it as foundational infrastructure. The ones still struggling are largely the ones that started with the model and discovered the data problem partway through.

But there is a category of operator for whom the data problem is not a project to complete. It is a structural feature of the way their assets work — and recognizing the difference is the first step toward solving it.

When one integration project is not enough

Linear assets — pipelines, electric transmission corridors, water distribution networks, rail track — have a fundamentally different data shape from discrete assets — compressor stations, treatment plants, substations, manufacturing cells. This is not about system variety or vendor fragmentation. It is about the underlying schema.

A linear asset management data model is topological. Assets are nodes and edges in a network. What matters is connectivity: which segments are upstream, which are downstream, how pressure or flow propagates across junctions. GIS coordinates are not a nice-to-have; they are primary keys. The right question about a pipeline segment is not just "what is its condition?" but "what is its position in the network, and what does that position mean for failure propagation?"

A discrete asset management data model is hierarchical. Assets are organized in a tree: facility → system → equipment → component. What matters is parent-child relationships: a bearing failure propagates up to a pump, which propagates up to a cooling system, which affects a process unit. OEE-grade telemetry flows upward through the hierarchy. ISO 14224 provides the taxonomy. The right question is not about network position but about failure mode inheritance.

These two schemas are not compatible. You cannot flatten one into the other without losing the structural information that makes them useful. Integrating a GIS-native network platform with a hierarchy-based CMMS is not a data engineering problem with a clean solution — it is an ongoing reconciliation burden that grows as both systems evolve.

For operators managing a gas distribution network alongside a treatment facility, or a rail corridor alongside maintenance depots, this means the 70% data-preparation tax does not fall once. It falls twice — against two separate data models, two integration maintenance obligations, and two reasoning systems with no shared context layer between them.

What a unified architecture actually changes

The difference between integrating two systems and running one unified system is not operational convenience. It changes what AI can reason about.

When network-aware and hierarchy-aware reasoning share a common data foundation, a pressure anomaly on a pipeline segment can be evaluated in the context of the facility assets at both ends. A maintenance window for a compressor station can be scheduled with visibility into the upstream network segments that need to compensate during the outage. A risk-based inspection priority list can rank both pipeline segments and plant equipment against a single risk framework, rather than producing two ranked lists that maintenance planners reconcile manually each week.

Condition-based maintenance programs, when they work as designed, cut unplanned downtime by 30 to 50% and reduce maintenance costs by 10 to 40%. Those figures are well-established. What is less discussed is the gap between those outcomes and what most mixed-portfolio operators actually see — and that gap is almost entirely attributable to data architecture, not to model quality or team capability.

The organizations currently closing that gap are not running better integration pipelines. They are reconsidering whether their EAM architecture was ever designed to hold both asset types in the first place.

The audit trail problem compounds this

There is a second consequence of siloed data models that matters specifically for regulated operators: decision traceability. NERC CIP, CISA OT guidance, and sector-specific inspection frameworks increasingly require that maintenance decisions — especially decisions to defer inspection or accept risk — be documented with supporting evidence.

A prediction from a model trained on data drawn from two incompatible systems is hard to audit. If the compressor station model and the pipeline network model each produce separate risk scores, reconciling them into a unified maintenance priority requires a judgment call that happens outside the system, in a spreadsheet or a planning meeting. That judgment call does not leave a decision log.

UniEAM's agentic platform is built on a single data foundation that holds both network topology and asset hierarchy without a translation layer between them. Network-aware agents model cascade risk across linear infrastructure. Hierarchy-aware agents surface failure modes through the asset tree. Every prediction carries a decision log — so maintenance teams and auditors can trace any recommendation back to the data, rather than treating model outputs as black-box guidance.

The 70% data-preparation problem does not disappear, but it becomes platform work rather than bespoke project work. That distinction matters at budget time, and even more at audit time.

The question worth asking first

Before the next AI or predictive maintenance initiative, the useful question is not "which model architecture performs best on our data?" It is: "where does that data actually live, and what does it cost us to keep it usable?"

For a detailed breakdown of how linear asset data models differ from discrete asset models in practice, and why that difference matters for AI accuracy, see our knowledge base on linear asset management.

Curious how UniEAM handles both? Request a demo.