AI in oil and gas: what survives contact with a Gulf operation

Every large operator in the Gulf has run an AI pilot by now. Most of them worked. Almost none of them are running on shift today, and the reason is usually the same: the pilot answered questions about a plant, and the plant needed something that could do work inside it.

This is a piece about the gap between those two things. It is written for the reliability engineer, the operations superintendent and the OT security lead who will be asked to sign off on whatever comes next, rather than for the person who has to write the business case. The business case is not the hard part in this region. Capital is available, the national strategies are written, the boards want the programme. What is scarce is the set of design decisions that lets an AI system live in a refinery, a gas plant or a drilling campaign for longer than a quarter.

Why the pilots stall

A typical proof of concept takes a data extract, puts a model over it, and demonstrates that the model can summarise a well file or spot an anomaly in a tag history. The demonstration is genuine. It is also the easiest 10 per cent of the problem, because a data extract has already had the three hardest properties of industrial data removed from it: it is stale, it is unsecured, and it is disconnected from the systems where work actually happens.

Reconnect those three and the pilot has to answer questions it was never built for. Which historian tag is authoritative when two sources disagree. Whether a contractor is allowed to see the drawing the model just cited. What happens when the recommendation is wrong at three in the morning. Who is accountable for the notification that got raised in SAP. None of these are model problems, and none of them are solved by a better model next year.

The organisations that get past this stop treating the model as the product. The product is the layer underneath it: the connectors, the permissions, the tool calls, the approvals and the audit trail. We call ours the Industrial AI Harness, and the name is deliberately boring, because the interesting part is not that a model can reason about a compressor. It is that the reasoning arrives with the tag trend, the work order history and the page of the OEM manual it was built from, in a form an engineer can check in fifteen seconds.

Read-only to the control layer, and mean it

The single fastest way to kill an industrial AI programme in this region is to arrive with an architecture that can write to the control system. It does not matter how well guarded the write path is. An OT security team that has spent a decade defending a Purdue-model boundary will not approve a language model on the wrong side of it, and they are right not to.

The workable posture is narrow and easy to state. Read SCADA, DCS and the historian. Never write a setpoint. Never touch a safety instrumented system. Where the AI takes an action, the action lands in a business system such as SAP PM or Maximo, as a draft, waiting for a named engineer to approve it. That posture is not a limitation imposed by nervous security people; it is what makes the thing deployable at all, and it maps cleanly onto the operational technology controls the Saudi National Cybersecurity Authority already expects operators to hold themselves to.

It also changes how you should read a vendor demo. If the demo shows an agent adjusting a process variable, you are watching a product that will not pass your OT review, however impressive the video is.

One chatbot for the plant is the wrong shape

The instinct is to build a single assistant that knows everything about the asset. In practice a single assistant is evaluated by nobody, because no one person can judge whether it is right. The drilling engineer cannot assess its answers on heat exchanger fouling and the rotating equipment specialist cannot assess its answers on stuck pipe risk, so the system gets a vague collective shrug instead of an owner.

Scope agents to one discipline each and the ownership problem solves itself. A reliability agent has a reliability engineer who will tell you within a week whether it is useful. A drilling agent is judged against the morning report. The agents share the same harness, the same connectors and the same audit trail, so this is a configuration decision rather than seven separate projects, but each one has a person whose job improves or does not.

Evaluate on your own failures, not on a benchmark

Public benchmarks tell you almost nothing about whether a system will be useful in your plant, because your plant has a specific population of failure modes, a specific alarm culture and a specific set of things the last three shifts got wrong. The evaluation that matters is a replay: take the last two years of events you know about, hide the outcome, and ask whether the agent would have caught them and how much noise it would have generated on the way.

Two numbers come out of that exercise and both are necessary. The first is how many of the known events it flagged, and how far ahead. The second is how many times it would have interrupted an engineer for nothing. An agent that catches every failure and cries wolf twice a shift will be muted within a month, and a muted agent is worth precisely zero regardless of what its recall number says.

• Replay known failures, near-misses and the false alarms your team already learned to ignore.
• Report lead time per event, not an average, because a six-hour warning and a six-day warning have different operational value.
• Count the interruptions the agent would have caused on quiet weeks, and treat that as the cost side of the ledger.
• Score the citations, not only the conclusion. An agent that is right for the wrong reason will be wrong later in a way nobody can predict.
• Rerun the whole replay after every material change to the agent, and keep the results. This is the artefact that gets you through audit.

The data is not in one place, and it does not need to be

Most operators have been told at some point that AI requires consolidating the estate into a single data platform first. That advice sells a multi-year programme and it delays every useful thing by the length of that programme. It is also increasingly out of step with how the industry is actually standardising: OSDU exists precisely so subsurface data can be addressed consistently without being centralised into one vendor's lake, and historians such as AVEVA PI already expose exactly the interface an agent needs.

The practical route is governed read access through connectors, in place. The historian stays the historian. SAP PM stays the system of record for work. The document system keeps owning the drawings and their revision state, which matters enormously, because an agent citing a superseded P&ID revision is worse than no agent at all. Nothing gets copied to get started, which is also the answer to the first question your data owners will ask.

Permissions are the feature, not the paperwork

In an operating company, access is already a solved and carefully argued problem. A contractor cannot open certain drawings. A field operator cannot see cost data. A joint-venture partner sees their asset and nothing else. Any AI layer that flattens this, even accidentally, creates an information disclosure route that did not exist before, and it will be found in the first penetration test.

The rule is that each agent inherits the access of the person using it, evaluated at query time, not at index time. If a contractor cannot open a document in the document system, the agent must not be able to summarise it for them either, and the answer they get must not reveal that the document exists. This constrains how you build retrieval, and it is worth the constraint.

Where it runs, in this region specifically

Operational data in Gulf energy companies is often subject to stricter internal rules than personal data. Production figures, reservoir information and turnaround plans are commercially and sometimes nationally sensitive, and a great deal of it sits on networks with no outbound internet by design. A vendor whose only deployment mode is a multi-tenant cloud in another continent is not a candidate, whatever the benchmark scores say.

Three deployment modes cover nearly every real case: a regional cloud tenancy inside the country, the operator's own cloud account, or on the operator's own servers including fully disconnected sites. The models run where the data is, which in practice means selecting models you can actually host, and accepting that the largest frontier model is not always the one you can use. In most of the workflows above, it is not the one you need either: extraction, classification, time-series reasoning and document question answering are well served by models small enough to run on hardware you can put in a plant.

The Kingdom's direction of travel helps here rather than hindering. The same authority that owns the Personal Data Protection Law owns the national data and AI strategy, so in-country AI deployment is policy rather than an exception being tolerated. The same is broadly true in Qatar and increasingly in Kuwait, where the constraint is less about whether AI is welcome and more about where the processing happens.

What a first project should look like

Pick one asset class or one workflow where the value is measurable and the data already exists. A compressor train. A drilling campaign. A set of ESP-lifted wells. Connect read-only. Replay the past. Go live with approvals on, and only then widen, because the second asset class reuses the connectors, permissions and evaluation harness from the first and therefore takes weeks rather than quarters.

The failure mode to avoid is the broad platform pilot that touches nine systems shallowly and produces a demo nobody owns. The pattern that works is narrow, deep, owned by a named engineer, and boring enough that it is still running six months later.

We build this the way we build everything else: engineers on site, working against the real historian and the real work order backlog rather than a specification written before anyone looked at the data. It is a slower way to sell software and it is the reason the deployments are still there in month six.