AI for oil and gas splits into two layers. Classical machine learning handles seismic interpretation, production forecasting and equipment failure prediction from sensor data, while language models and agents handle the documents that run the business: daily drilling reports, well files, HSE incidents and permits, maintenance work orders, regulatory filings and joint operating agreements. Because those documents sit next to operational technology covered by IEC 62443 and, for US pipelines, TSA security directives, operators usually run the language layer on servers they control, sometimes at sites with no reliable connection.
Where AI fits in the oil and gas industry, from upstream to downstream
Oil and gas companies already run more machine learning than most industries. What is new is AI that reads and writes. The useful split for a buyer is by the kind of data a task consumes.
| Segment | Document work that suits language models | Numerical work that suits classical ML |
|---|---|---|
| Exploration | Searching past studies, drafting interpretation reports | Fault, horizon and salt segmentation in seismic volumes |
| Drilling and completions | Daily drilling report summaries, lessons learned, well program drafts | Rate of penetration optimisation, stuck pipe and kick detection from rig sensors |
| Production | Well file search, workover history, regulatory reporting drafts | Decline curve forecasting, artificial lift optimisation |
| Midstream | Pipeline procedures, integrity reports, control room handover notes | Leak detection models, compressor anomaly detection |
| Refining and petrochemicals | Permit-to-work records, management of change packages, incident reports | Process optimisation, soft sensors, heat exchanger fouling prediction |
| Corporate | Contracts, joint operating agreements, joint venture reporting | Trading and price forecasting models |
The rest of this guide covers the document column, where generative AI and agents add the most, and explains why the numerical column should stay with the tools built for it.
Drilling reports and lessons learned
Every rig produces a daily drilling report. The International Association of Drilling Contractors calls its DDR format the standard for reporting drilling performance and notes that most drilling contracts use it for legal reporting. Real-time rig data often moves in WITSML, the XML-based well data standard maintained by Energistics.
A well generates dozens to hundreds of these reports, and a field generates thousands. The free-text remarks hold the knowledge: why a trip took longer than planned, which mud weight finally controlled losses, what the crew changed after a twist-off.
A language model with retrieval over the DDR archive can do three things well:
- Summarise one well. Turn the full report set into a timeline of non-productive time events with causes, in a format the drilling engineer can edit.
- Find similar events. Answer “which offset wells had losses in this formation, and what worked” with links to the reports.
- Draft the lessons learned register. Propose entries from the end-of-well review, for the drilling superintendent to accept or reject.
The model reads the remarks; the time codes and depths come from structured fields. Keep that separation, because a model that guesses a depth from prose is worse than a query.
Well files and engineering document search
A producing asset carries decades of paper: completion reports, workover records, wellbore diagrams, regulatory permits, integrity test results and correspondence with partners. Much of it was scanned without good indexing, and asset transfers between companies made it worse.
Engineers spend hours finding a casing test from 1998 or the last time a well was acidised. A retrieval assistant over the well file, with OCR applied to the scans, answers those questions with a citation to the page. It can also flag gaps, for example a well with no integrity test recorded after a workover.
The field and engineering knowledge use case and the OT documentation Q&A use case show how the same pattern works for utilities and other operators with large technical archives.
HSE incident analysis and permit-to-work
Safety documentation is heavily regulated, which makes it a good fit for drafting and a poor fit for automation without review.
At US refineries, gas processing plants and other covered processes, OSHA’s process safety management standard at 29 CFR 1910.119 requires a hot work permit for hot work on or near a covered process, in paragraph (k), and an investigation of every incident that resulted in, or could reasonably have resulted in, a catastrophic release, in paragraph (m). The standard exempts oil and gas well drilling and servicing. On the US Outer Continental Shelf, BSEE’s safety and environmental management system rules in 30 CFR Part 250, Subpart S, set criteria for hazards analysis in 250.1911 and incident investigation in 250.1919.
Agents help with the paperwork those rules create:
- Incident investigation drafts. Collect the permit, isolation certificates, shift handover notes and witness statements, build a timeline and draft the report sections. The investigation team decides causes and actions.
- Trend analysis across near misses. Group free-text near miss reports by hazard and location, which is hard to do with keyword search because crews describe the same hazard in many ways.
- Permit review support. Check a draft permit against the procedure and the job safety analysis for missing isolations or gas tests, and flag them for the issuing authority. The model never issues or signs a permit.
Maintenance work order triage in SAP PM and Maximo
Most operators run maintenance in SAP Plant Maintenance or IBM Maximo. Both vendors now offer AI features. IBM’s announcement of Maximo Application Suite 9.2 in June 2026 describes agentic workflows, a Maximo Assistant for technicians on mobile and an MCP server for the Maximo Manage APIs. SAP describes an asset operations assistant that coordinates Joule agents for maintenance request screening, maintenance planning and technician briefing. These features run in the vendors’ own environments, so check what each one sends where before enabling it.
The work they target is real. Planners face hundreds of new notifications a week, many with vague descriptions, wrong failure codes or duplicates. An agent can read each request, compare it with the equipment’s history and similar past orders, suggest a priority and failure code, and draft a job plan with parts and permits. The planner approves, edits or rejects each suggestion.
For predictive maintenance itself, the anomaly score comes from sensor models, not from a language model. The predictive maintenance analysis use case covers how the two connect: the model raises the alert, and the agent explains it with the history and drafts the notification.
Regulatory filings, contracts and joint operating agreements
Operators file a steady stream of reports with production, environmental and safety regulators, and each filing draws on data and narrative from several departments. A language model can draft the narrative sections from approved internal reports and check that figures in the text match the source tables. A compliance owner reviews and submits.
Contracts are the other large corpus. Joint operating agreements, production sharing contracts, farm-out agreements, drilling contracts and master service agreements govern who pays, who decides and who is liable. Typical questions are “which of our JOAs require partner consent for this kind of expenditure” or “which service contracts carry a knock-for-knock indemnity.” Retrieval with citations answers them across hundreds of agreements, and an agent can build a comparison table for the commercial team.
Contract data is commercially sensitive and often confidential under the agreements themselves, so the same deployment rules apply as for technical data.
Seismic, production and sensor data belong to classical ML
Be clear with internal stakeholders about what a language model will not do. It will not pick faults in a seismic cube, history-match a reservoir model or predict when a compressor will trip. Those tasks use convolutional networks, physics-based simulators, regression and anomaly detection, trained and validated on numerical data.
Published work shows how mature this is. The FaultSeg3D paper in Geophysics in 2019 trained a convolutional network on synthetic seismic data to segment faults in 3D. Interpretation platforms now ship comparable features, and they run on GPU workstations inside the operator’s network.
The language layer adds value at the edges of this work: searching past interpretation reports, drafting the summary for a partner meeting, or explaining in plain language what a forecast model changed. Treat any proposal that puts a chat model in charge of a numerical prediction as a red flag.
Why OT security and remote sites push AI on-premises
IEC 62443 and the boundary around control systems
The ISA/IEC 62443 series defines requirements for securing industrial automation and control systems. Part 3-2 covers risk assessment and the division of a system into zones and conduits, part 3-3 sets system security requirements and security levels, and part 2-1 sets requirements for the asset owner’s security program. Control system data such as alarm logs, historian exports and process graphics often reveals how a facility can be attacked. An AI service that reaches into a control zone, or receives its data over an unmanaged path, adds a conduit that the 62443 risk assessment has to cover.
CISA’s May 2025 fact sheet on primary mitigations for operational technology makes the same point in practical terms: keep OT off the public internet and segment IT from OT. A model served from the corporate data centre, reading copies of OT data that cross a controlled boundary, respects that design.
TSA pipeline security directives in October 2026
US pipeline owners and operators designated by TSA are subject to two security directive series. Security Directive Pipeline-2021-01G took effect on 16 January 2026 and runs to 15 January 2027. Security Directive Pipeline-2021-02G, on cybersecurity mitigation actions, contingency planning and testing, took effect on 3 May 2026 and runs to 2 May 2027, with TSA stating it made no substantive revisions to the previous version. TSA’s proposed rule on surface cyber risk management, published in November 2024, had not been finalised by 22 October 2026, and the federal regulatory agenda lists it as a long-term action. API Standard 1164, third edition, covers pipeline control system cybersecurity.
None of these documents mentions AI by name. They do require operators to segment control systems, control access and monitor for threats, and any AI tool that reads pipeline control data falls inside that scope.
Offshore platforms and remote sites
Offshore platforms, remote well pads and FPSOs often rely on satellite or microwave links with limited bandwidth and high latency. A cloud assistant that needs a round trip for every question is slow at best and unavailable when the link drops. A model served on a small GPU server on the installation, synchronised with onshore when the link allows, keeps procedures and equipment history available to the crew. For fully disconnected sites, the guide to AI on restricted and air-gapped networks covers offline model transfer and updates.
National oil companies and data sovereignty
National oil companies and their partners often operate under national rules on where data may be stored. Saudi Arabia is a useful example of how these rules move: the 2018 version of the National Cybersecurity Authority’s Essential Cybersecurity Controls required hosting and storage inside the Kingdom, and the 2024 revision removed that control and referred data localisation to the National Data Management Office. Requirements change, so check the current text in each jurisdiction. Running models in-country, on infrastructure the company controls, avoids most of the question.
A governed reference architecture for operators
| Layer | What sits there | AI design rule |
|---|---|---|
| Control systems (field and plant) | PLCs, SCADA, safety systems, historians | No AI connection; data leaves only through approved conduits |
| Operations DMZ | Historian replicas, data diodes, file transfer | Exports copies of data for analysis |
| Corporate data centre or in-country cloud | Model servers, retrieval index, agent platform, audit logs | Local models, permission-aware retrieval, human approvals |
| Remote site edge | Small GPU server with a local index of procedures and equipment history | Works offline, syncs on a schedule |
| Business systems | SAP PM or Maximo, document management, contract repository | Agents get read tools first; write actions need approval |
Four rules make this work in practice. Agents start with read-only tools and earn write access one action at a time. Every prompt, retrieved document and tool call is logged with the user and model version. External model APIs stay off for anything touching control data, well data or contracts. And model updates go through the same change management as other operational software.
How VDF AI fits oil and gas operations
VDF AI installs on an operator’s own servers, in a corporate data centre, an in-country private cloud or an air-gapped site. The models, retrieval indexes, conversation history and audit logs stay inside that environment, which keeps drilling data, well files and contracts away from outside model providers. VDF AI has no certification of its own; it sits inside the operator’s 62443 zones, TSA directive scope and internal security assessment like any other application.
The workflows above become governed agents and multi-agent networks. A maintenance triage agent reads the notification and equipment history, drafts the priority and job plan, and stops at a human approval step before anything is written back. An incident agent assembles the permit and shift records and drafts the investigation outline for the team lead. Retrieval follows the permissions of each source system, and each turn records the user, model version, retrieved passages and tool calls. VDF AI Router serves requests from registered local endpoints such as vLLM or Ollama, and its air-gap mode removes every external route, which suits offshore and remote sites.
On-premises, users sign in through Microsoft Entra ID single sign-on with security groups mapped to roles; other identity providers connect through an SSO-aware reverse proxy. A deployment can begin with a three-month platform trial. For more detail, see the energy and utilities solution, the critical infrastructure solution, the critical infrastructure and energy executive brief, the field service agent and the guide to on-premises AI for energy and critical infrastructure.
This guide summarises rules for planning and is not legal advice.
Sources
- TSA security directives and emergency amendments listing
- TSA Security Directive Pipeline-2021-02G and transmittal memo (May 2026)
- TSA Security Directive Pipeline-2021-01G and transmittal memo (January 2026)
- TSA proposed rule, Enhancing Surface Cyber Risk Management, 89 FR 88488 (7 November 2024)
- Unified Agenda entry for RIN 1652-AA74
- ISA overview of the ISA/IEC 62443 series
- API Standard 1164, pipeline control systems cybersecurity
- CISA fact sheet on primary mitigations for operational technology (May 2025)
- OSHA process safety management standard, 29 CFR 1910.119
- BSEE SEMS rules, 30 CFR Part 250 Subpart S
- IADC Daily Drilling Report reference
- Energistics WITSML data standards
- The Open Group OSDU Forum
- IBM announcement of Maximo Application Suite 9.2 (June 2026)
- SAP asset operations assistant with Joule agents
- Wu, Liang, Shi and Fomel, FaultSeg3D, Geophysics 84(3) (2019)
- Saudi NCA Essential Cybersecurity Controls ECC-2:2024