Your production facilities run on infrastructure that was reliable decades ago and has become essential today. Retrofitting a new control stack — ripping out PLCs, historians, flowmeter systems and SCADA — is not a real option. A platform shutdown costs more than the entire AI budget that was supposed to prevent it. So when you want anomaly detection, predictive maintenance and the shift from reactive firefighting to proactive intervention, you are choosing between deploying on what is already there, or not deploying at all.
The facilities that moved the needle — cutting unplanned downtime 40% across upstream and downstream operations — did it by dropping predictive models onto the existing SCADA and historian infrastructure. Not over it. Not beside it. Into the control loop that already works.
Why rip-and-replace fails in oil & gas
The reflex in software is to replace. New capability means a new platform, new infrastructure, new training for the teams that run it. In upstream and downstream oil and gas, that reflex kills projects before they ship.
A drilling platform or a processing facility is not a data center. Downtime cascades — one stalled unit can back up an entire production train. The people who maintain the equipment have spent years learning the temperament of their specific pumps, compressors, flowmeters and sensors. They know which alarm usually means something and which one fires every Tuesday for no reason. They trust the SCADA because it has earned that trust through reliability.
When a vendor proposes to tear out the historian, the flowmeter interface and the PLC network and rebuild it around a "modern" stack, the plant engineer does not see progress. They see risk. And they are right. Every hour the rebuilt system spends in validation is an hour the operation is betting that something untested is as safe as the thing it replaced.
The alternative — the one that actually ships — is architectural surgery rather than amputation. Keep the control spine intact. Drop the anomaly models on top of it. Read the data the historian is already collecting, at the telemetry rate it already streams. Write the alerts back into the SCADA console your maintenance teams are already watching. No new network. No new power infrastructure. No months of integration testing to prove a rebuilt system is as safe as the one it replaced.
This is the difference between data gravity working against you and working for you. In oil and gas the data — and the risk of touching it — is the gravity. A brownfield approach meets the plant where it is: the AI comes to the data, not the data to the AI.
The architecture that crews trusted
The moment a model goes live in an operations room, it enters a brutal accountability regime. Crews act on alerts that prove true. They ignore — or curse — alerts that turn out to be noise. A flag that sends a technician out to a pump that is running fine costs trust, and once the model loses trust it loses adoption. The detection rate on a slide means nothing if the false-positive rate is high enough that crews stop believing the screen.
The systems that shipped used a hybrid architecture: statistical process control — the control-charting discipline manufacturing learned decades ago — fused with a deep-learning autoencoder ensemble. The SPC layer establishes what "normal" looks like for each piece of equipment, and normal varies. A flowmeter on an injection well has a different baseline than a flowmeter on a production well. A pump running at half capacity has a different signature than one at full bore. The autoencoder learns the temporal patterns — the time-series rhythm of a healthy system — across multiple time scales, so it can separate normal operational variation from degradation that precedes failure.
That two-layer defense hit the under 2% false-positive target. Raw deep learning often performs worse than hand-engineered features in noisy industrial telemetry, because it latches onto patterns that are artifacts of the sensor rather than the asset. Pairing the autoencoder with SPC — forcing the model to respect statistical control boundaries instead of inventing its own — is what kept the false-positive rate low enough that crews would act on every alert.
The architecture also has to respect that anomalies are not one thing. A point anomaly is a single reading that is wrong — a spike that should not be there. A contextual anomaly is a reading that is normal in isolation but wrong for the moment: a flow rate that is fine at full production and alarming during a ramp-down. A collective anomaly is a sequence that is individually unremarkable but collectively abnormal — the slow, correlated drift of several readings that together signal a developing fault. Specializing detection for point, contextual and collective anomalies lets crews triage genuine events instead of chasing noise.
- 95%
- Detection rate
- <2%
- False positives
- 40%
- Fewer unplanned stops
- 25%
- Lower maintenance cost
Facility two: data mapping, not control rework
The real test of a brownfield strategy comes at the second location.
The first facility is a beachhead: you prove the model works, crews adopt it, maintenance cost drops. The open question is whether the result transfers. In a rip-and-replace scenario, facility two means another new control stack, more training, more months of validation — and that cost structure is what makes it impossible to deploy beyond a flagship site.
Facility two on the same brownfield playbook means something far smaller: map the data sources (which historian database, which flowmeter telemetry stream, which PLC network the facility is wired into), establish baselines for the equipment types present there, and deploy the ensemble. No new infrastructure. No new training, because the SCADA console your operations team uses is still the SCADA console. The alert rules do not change, because they live in the software, not the hardware. Time-to-deployment collapses from months to weeks.
Once you have proven the model works at facility one without touching the control infrastructure, adding the next facility is an operational change, not an engineering project. The model is agnostic to facility layout and equipment vintage so long as the telemetry is there. Heterogeneity — equipment from multiple vendors, different vintages, different calibration regimes — is handled by re-establishing baselines per asset, not by rebuilding the model. You are mapping data, not rewiring plants.
Sustain: living with sensor drift and shifting baselines
The hard part of operating anomaly models in oil and gas is not the initial deployment. It is holding the detection rate steady as the baseline drifts underneath it.
Equipment ages. A flowmeter that was accurate early in its life drifts as its internals wear. A compressor bearing gets replaced with a slightly different part that carries a marginally different vibration signature. A well starts pumping water mixed with the crude as the reservoir matures. Any of those shifts the "normal" the model originally learned. If you do not retrain, the false-positive rate climbs — either because the model starts flagging things that are now normal for the aging equipment, or because it stops catching real anomalies.
The teams that kept the alert rate stable did two things. First, they tuned the retraining cadence to the maintenance rhythm of the facility rather than to a generic calendar. On a platform built around scheduled turnarounds, you retrain the baseline at the end of each turnaround, using the clean-operation data that follows it — equipment you know is healthy because it was just serviced. On a flowing pipeline or processing plant where equipment is replaced continuously, you retrain on a rolling window so the model is always learning from recent, confirmed-healthy assets.
Second, they monitored the alert rate itself as a signal. If the number of alerts per week starts climbing, that is information either way. It can mean the equipment is genuinely degrading faster than expected — which is exactly what you want to know — or it can mean the model baseline has drifted too far from the current equipment population. Watching the rate of change of alerts lets maintenance teams tell the difference between "our compressors are getting noisier than usual, let us plan more inspections" and "the model is out of sync, retrain it before crews start chasing phantom faults." That distinction is what keeps an anomaly model honest in year three, not just at launch.
This is why sustain is a discipline, not a maintenance task. Operations AI lives or dies on alert trust. Monitoring for drift and retraining to hold detection sensitivity high while keeping false positives below the threshold crews will act on is what sustains the reactive-to-proactive shift across every monitored facility.
Once you prove the model works at facility one without touching the control infrastructure, adding facility two is an operational change, not an engineering project. The data maps differently. The equipment has a different vintage. The alert rules stay the same because they live in the software, not the hardware.
The assess phase: where you uncover facility opportunity
Deploying anomaly detection at a single facility is not a rip-and-replace decision. It is a readiness audit: mapping the telemetry sources, establishing which failure modes cost the most, and understanding what your historian and SCADA can actually deliver before a line of model code is written.
In the 4–6 week assess phase, the work is concrete. You inventory the flowmeter streams connected to the historian — how many points, what sampling rate, how long the retention window runs. You pull a sample of rotating-equipment data: vibration on compressors and pumps, bearing temperatures, discharge pressures. You identify the well-log sources and check whether they stream continuously or arrive on a batch schedule. You map the PLC network and learn which alerts already route to the SCADA and which sit in vendor-specific dashboards nobody opens.
Then you establish per-asset baselines. A flowmeter on an injection well is not a flowmeter on a production well. A centrifugal compressor behaves differently from a reciprocating pump. Your data looks heterogeneous because your assets are heterogeneous — different vendors, different vintage, different calibration regimes. The assess phase untangles that. For each major equipment class at the facility, you pull a window of clean operation, when you know the equipment was healthy, and establish what normal looks like for that class under its real operating conditions.
Finally, you rank by opportunity: which failure modes cost the most downtime, which cost the most maintenance, which are most visible in the telemetry. A bearing failure on a critical-path compressor is high-cost and shows up clearly in vibration data — a strong first target. The output of assess is a ranked roadmap scoped to your existing control infrastructure: start with rotating-equipment anomaly detection on the mission-critical compressors, add flowmeter anomaly detection on the injection string, and plan well-log interpretation for a later phase.
That roadmap — built on your actual infrastructure, your actual equipment, your actual costs — is what makes the business case real instead of aspirational.
Where to start
The shift from reactive maintenance to proactive intervention is not one big bang. It is building the model that proves the case at the facility where the cost of downtime is highest, the telemetry is cleanest, and the maintenance team is most skeptical and most influential — because once the hardest crowd believes the alerts, the rest of the network follows.
Start there. Four to six weeks to map your data, establish baselines, and rank where detection pays back fastest. Then build the anomaly model for the one failure mode that will save the most money, and prove the approach works without touching the control infrastructure. Run it. Let the cost savings speak for themselves.
Then facility two is not a project. It is a scaling operation.
“In oil and gas, the data gravity is the risk; deploying on the infrastructure already there is what makes the shift from reactive to proactive shippable across facilities.”
Get in touch
Put RealAI’s applied-AI team on your hardest data problem.
We help enterprises move from pilots to production — sovereign models, governed data, and agents you can audit. Start with a value-first assessment.