Most oil and gas companies are now expected to have an AI strategy. Their boards want one, and a steady stream of vendors arrives with pilots to sell. In maintenance and reliability the interest is well founded. There are real gains available from applying machine learning, and more recently language models and agents, to the work of keeping equipment running.
The difficulty tends to appear later. Many of these pilots never move past the proof-of-concept stage. A model performs well in a demonstration built on cleaned sample data, then fails to hold up once it meets the plant’s real records. This article walks through where AI can help in maintenance and reliability, and then explains what a site needs to have in place before that help is available.
Examples of AI in maintenance and reliability
Consider a condition-monitoring agent assigned to a compressor train. It watches vibration and temperature data and compares what it sees against the failure history of similar machines across the company’s sites. When a bearing begins to show a pattern that matched fourteen earlier failures, the agent identifies the specific bearing from the machine’s bill of materials, checks whether the spare is in the storeroom, and prepares a work order with the replacement procedure and the parts list. A person reviews and approves it. The repair happens during a planned outage rather than after an unplanned trip. On equipment where a failure means a lost shift of production or more, most of the value comes from catching the problem early and having the right part ready.
A second case is preventive maintenance that adjusts itself. Most plants service equipment on fixed calendar intervals, so a pump is maintained every ninety days whether or not it needs it. Some of that effort is spent on equipment in good condition, and some failures still occur between intervals on equipment that was degrading faster than the schedule assumed. A system with access to condition data and failure history can set the interval for each asset according to how that asset is behaving, and revise it as conditions change. The effect is less labor spent on healthy equipment and fewer failures on equipment that needed attention sooner.
A third case is a natural-language interface to the plant’s own information. An engineer could ask which assets in a given unit are running past their expected bearing life, and what the exposure would be if two of them failed in the same quarter. Answering that today means working through maintenance records and equipment manuals and then finding whoever remembers the relevant history, which can take most of a day. A system that has the underlying data organized can answer the same question in the time it takes to read it. Information that currently sits with a few long-tenured staff becomes available to anyone on the team.
A fourth case is finding causes that are hard to see from inside a single site. When failure data is recorded consistently across many units and locations, a model can look for patterns that no individual engineer is placed to notice. It might find that a particular bearing only fails when it is installed alongside a specific motor model, and trace the cause to an alignment step in the installation procedure. A finding like that lets a company correct a recurring problem across its whole fleet instead of replacing the same part again and again at each site.
A fifth case is spare-parts inventory. Companies tie up a great deal of cash in spares, much of it in parts that are rarely used, while critical spares occasionally run short when they are needed. A system that accounts for each asset’s condition and criticality can hold the right parts in the right quantities. That releases working capital and lowers the chance of waiting on a part while a machine sits idle.
The reason pilots stall
None of these examples requires a research breakthrough. The models and tools involved are available today, and the cost of using them continues to fall. Given that, it is reasonable to ask why so many of these projects stall.
In most cases they stall on the data. Each of the five examples assumed the system already knew several things: which physical asset it was dealing with, where that asset sits in relation to the rest of the plant, what parts it is built from, and what has happened to it over its life. In a large share of plants, some of that information is incomplete and some is simply missing.
This is not a hypothetical concern. In many operations the item and material master, which is the record of the parts actually installed, is only twenty to thirty percent complete. The same piece of equipment is often stored under several different names, and the hierarchy meant to describe how equipment is organized has gaps in it. Failure history is usually written as free text with no consistent coding. Together this forms the layer of asset registration, item master, and maintenance data that everything else has to sit on.
Why automated systems need cleaner data than people do
There is a common assumption that AI will make up for messy data, that a capable enough model will work around the inconsistencies on its own. In practice the opposite is closer to the truth, and the reason is worth setting out.
An engineer who has worked at a site for years can function despite a messy registry. They know that the pump labeled 7A is the one the crew still calls the old Gould, and that two separate entries in the system refer to the same machine. They fill the gaps with memory and judgment. A software agent has none of that. It works from the records as they are written, and if the records are wrong its conclusions are wrong, with no independent sense that anything is off.
For that reason, the level of data quality required for AI to run reliably is usually higher than what a maintenance organization run by people has been getting by with. The informal knowledge that lets experienced staff work around bad data is the thing an automated system does not have. For the model, the asset and item records are the only description of the plant it has. They establish what exists and how the items connect to each other, and they hold the recorded condition of each one. When that description is poor, the system draws the wrong conclusions from the data it is given, and in some cases cannot operate at all.
What a sound data foundation looks like
It helps to be specific about what a sound foundation involves, so that this reads as a solvable problem. An asset registry should be complete and structured correctly, with a functional-location hierarchy that reflects how the plant is really arranged. Item and bill-of-material data should be linked to the assets that use those parts. Failures should be recorded with a consistent taxonomy, such as the one defined in ISO 14224, so that the same kind of failure is coded the same way everywhere; that consistency is what allows a model to find patterns across the fleet. Criticality and operating history should stay attached to each asset. This is unglamorous work, and whether it gets done is what decides which of the applications above are realistic for a given site.
Where this leaves operators
Over the next few years, the operators that get real value from AI in maintenance and reliability will largely be the ones whose asset data is in good enough condition for these systems to run on. The models are becoming widely available and are not where the lasting advantage will be. The harder and more durable work is in the data underneath them. A company that wants the capabilities described here is better served by treating the state of its asset and item records as the first task rather than a later cleanup.
The data is one of two foundations these systems depend on. The other is the operation and the people around the tools, which is covered in the operational foundation for AI adoption.
This is part of the work 2E does. A transformation in oil and gas begins with an assessment of the systems, records, workflows, and controls that the intended result will depend on. Where the maintenance data is not ready, 2E builds and rebuilds the asset registration, item master, and maintenance records before a system migration, predictive-maintenance workflow, automation, or AI application relies on them. If an organization is planning for AI in maintenance and reliability and is unsure whether the underlying data is ready, that is a sensible place to begin.
