AI Patterns for Gas Transmission Operations
Gas transmission system operators in the GCC sit on three rivers of data: SCADA telemetry from compressor stations and metering skids, in-line inspection logs from pigging runs, and a decade of integrity-management PDFs written by engineers who have since rotated. The shape of the AI opportunity is obvious. The shape of the risk is more so. This piece walks through four patterns we see working for gas-transmission TSOs in the region, all anchored to an on-prem inference posture rather than public-cloud calls.
1. The operational data the TSO already owns
A typical national gas-transmission operator generates roughly the same data classes regardless of country. Treating the AI question as a data-engineering question first, before a model question, removes most of the failure modes.
- SCADA and historian streams. Pressure, temperature, flow, valve states, compressor RPM, vibration, sampled at 1 to 10 second intervals across hundreds of remote terminal units. A mid-sized TSO will hold years of this in a process historian.
- Pigging and in-line inspection logs. MFL, ultrasonic, and caliper datasets per pipeline run, plus the engineer-written assessment that translates raw signals into corrosion classes, dent severities, and re-inspection intervals.
- Integrity and incident reports. RBI assessments, fitness-for-service calculations, near-miss reports, root-cause analyses, all PDFs, often bilingual Arabic and English.
- Maintenance and CMMS records. Work orders, spare-part consumption, vendor-callout logs, valve-stroke histories.
- GIS and ROW data. Pipeline alignment, soil class, crossing inventory, third-party-encroachment incident history.
None of this is exotic. The lesson from the broader literature on AI for gas pipeline safety and efficiency is that the gating constraint is rarely the model, it is whether these five sources can be queried together with a stable schema.
2. AI patterns that are actually shipping
Three patterns dominate the production-grade work we see, and each maps to one of the data classes above.
- Streaming anomaly detection on SCADA telemetry. Classical ML (Random Forest, gradient boosting) and compact deep models (1D CNN, LSTM autoencoder, transformer encoder) flag deviations from a learned operational envelope per asset. Recent work such as DeepPipeNet reports detection accuracy above 98% on multivariate pipeline telemetry. The TSO use is not just leak detection. It is also catching valve stiction, transmitter drift, and compressor surge precursors before they raise an OT alarm.
- Predictive maintenance from inspection PDFs. A retrieval-augmented LLM ingests pigging reports, integrity assessments, and CMMS notes for a given pipeline segment, then answers the engineer's actual question: which segments are due for re-inspection, which corrosion features are growing, what was the last documented mitigation. The model does not replace the integrity engineer. It collapses three days of PDF archaeology into a 20-minute review.
- Leak and incident narrative drafting. When a notifiable event occurs, the operator owes a structured narrative to the regulator within a fixed window. An on-prem LLM, primed on the operator's prior incident reports and HSE format, drafts the narrative from raw SCADA traces, valve-position logs, and operator-console screenshots. The HSE lead edits and signs. The drafting time drops from hours to minutes without the model ever leaving the perimeter.
For a deeper read on building AI workflows that survive sovereign-data review, see our AI defence Arabic document triage pillar, which sets out the trust-boundary discipline these gas-operations patterns inherit.
3. OT-network isolation, the non-negotiable
Every pattern above must respect the Purdue-model levels. The rule is simple: AI models never sit on Level 0 to 2. They consume a one-way replicated copy of historian data in a separate analytics enclave, typically Level 3.5 DMZ or a dedicated Level 4 zone with a data diode or unidirectional gateway between historian and replica.
- No model writes back to a controller. Ever. Recommendations land in a ticketing queue that an operator approves under existing change-control.
- The replica is read-only by construction. Even a compromised model cannot send a setpoint.
- Vendor remote support reaches a jump host, with full session recording, never the model server or the historian.
- The model server runs on a separately hardened OS image, patched on the same SIS-aligned cadence as safety-instrumented systems.
This posture also keeps the auditor's life simple. The OT network's risk profile does not change because the back-office added an LLM.
4. On-prem architecture that fits a control-room budget
The architecture splits cleanly along latency lines.
- Edge tier. A pair of small servers in the control room running compact anomaly-detection models against the historian replica, returning scores in under 200 ms. RTX 6000 Ada or even high-end CPUs are sufficient at this scale.
- Back-office tier. A small GPU rack (2 to 8 H100/H200 class accelerators) hosting a 70 to 120 billion parameter LLM, an embedding model for the document corpus, and a vector store. This is where the inspection-PDF and incident-narrative work runs.
- Storage and replication. One-way data diode from historian to replica, an S3-compatible object store for documents, a Postgres or Mongo metadata layer, and an audit log immune to the model tier.
- Operations. Models, prompts, retrieval indices, and evaluation sets are versioned. Every inference logs prompt, retrieved context, and output. The HSE and integrity teams own the eval set, not the vendor.
For the network architecture itself, our air-gap network architecture for AI piece details the diode, jump-host, and zoning patterns. For corpus discipline on the inspection-PDF side, the OQ EP knowledge-base AI walkthrough covers ingestion patterns that translate cleanly to a TSO setting.
5. Where to start
The wedge that gets fastest sign-off is almost always the inspection-PDF assistant, because it touches no live OT systems, sits behind the existing document-management ACLs, and creates daily-visible time savings for integrity engineers. SCADA anomaly detection follows once the analytics enclave is in place. Incident-narrative drafting comes last, because it touches HSE-regulated outputs and needs the most careful eval discipline.
Email [email protected] for a one-hour briefing on shaping a gas-operations AI program around your historian, your inspection corpus, and your existing OT zoning.
Frequently asked
Can AI models touch a live SCADA network?
No. The pattern that survives audit is a one-way replication of historian data into a separate analytics enclave. Models read a copy of telemetry, never the live OT bus, and never write back without a human-approved change ticket.
What kind of model size is realistic for a TSO control room?
Two layers. Small classical ML or compact deep models for streaming SCADA anomaly detection, often under 100 million parameters, run at the edge or on a control-room workstation. A larger 70 to 120 billion parameter language model handles inspection PDFs and incident narratives in a back-office GPU rack.
Does an on-prem deployment still allow vendor support?
Yes, through a brokered out-of-band channel. The vendor reaches a jump host with logging and recording, never the model server or the historian replica. Patching follows the same change-control flow as any safety-instrumented system.
Why not use a cloud LLM for the inspection-PDF work?
Pigging reports, integrity assessments, and incident narratives are commercially sensitive and often subject to national security review. Sending them to a foreign-jurisdiction LLM creates legal and disclosure exposure that on-prem inference avoids entirely.