AI in Asset Integrity Management for Oil & Gas Malaysia: What Actually Works, and What Doesn't

Every third week this year, a senior integrity engineer at a Malaysian or ASEAN operator has asked me some version of the same question.

"A vendor just walked us through an autonomous AI agent that promises to rank our RBI portfolio. It looked polished. Is this the future?"

This post is the honest field answer for anyone evaluating AI in asset integrity management in oil and gas Malaysia right now, whether you own the integrity function inside an operator, run an integrity consultancy, or sit on the digital and AI side of the same organisation.

The honest answer is that the pitch decks are ahead of the technology, and the technology is ahead of the regulator's tolerance for anything that cannot be explained line by line. Asset integrity is one of the few enterprise domains where an unexplained decision is a compliance event, not a productivity gain. That means most of what is being pitched as "AI for asset integrity" today does not survive a serious integrity engineer reading the fine print.

That does not mean AI has no place in this work. It has a real place. But you have to be honest about which parts of PIMS, SIMS, and RBI actually benefit from AI, which parts benefit from classical machine learning, and which parts should stay as the deterministic rule sets they already are. This post is that breakdown.

We build Enrise, an asset integrity platform, jointly with our engineering partner Optitech, an integrity consultancy with live project experience in Malaysia and Vietnam. What follows is what we have learned building it, and what we tell integrity managers when they ask us the RBI-vendor question.

Why asset integrity is not a normal AI use case

Most enterprise AI conversations start with the assumption that if a model is more accurate than a human on a benchmark, we should let it decide. Asset integrity does not work that way, and it is important to understand why.

Every RBI framework worth trusting, API 580 and 581, DNV RP-G101, ASME, exists because a regulator or an insurance regime needed a defensible answer to the question "why did you inspect this asset at this frequency?" The frameworks encode risk into two dimensions, probability and consequence, using explicit engineering inputs. That structure is what makes the output auditable. A regulator can walk backwards from "we inspected pressure vessel V-1204 every 18 months" through the RBI score, into the probability calculation, into the corrosion loop, into the operating conditions, into the inspection history. Every step is documented. Every step is engineerable.

Drop a black-box model into that chain and the regulator's audit stops working. Your integrity engineer cannot explain why a specific asset was ranked the way it was. Your HSE reviewer cannot check whether the reasoning is sound. Your insurance underwriter cannot reproduce the calculation. In a serious operator, that alone kills the project.

This is why the "give the AI the whole RBI portfolio and let it decide" pitch fails on second reading. It also explains why the honest answer is not "no AI in integrity" but "AI in specific bounded places where explainability can be preserved."

The four automation patterns, applied to integrity

We wrote about the four patterns for enterprise automation in general. They apply cleanly to integrity work, once you know where each pattern actually fits.

1. Rules-based automation. The RBI engine itself. Corrosion rate calculations. Inspection interval math. Data validation on ingested inspection reports. These are deterministic engineering rules, most of them codified in standards. They do not need AI. Building them as rules keeps them auditable. This is the majority of the RBI codebase and it should stay that way.

2. Classical machine learning. Anomaly detection on inspection data. Outlier detection on sensor telemetry. Corrosion rate forecasting where enough historical data exists. Fatigue crack propagation modelling. These are well-understood ML tasks with decades of maturity in adjacent fields. They are cheap to run, straightforward to validate, and their outputs are numerical enough that engineers can reason about them. The catch is that "classical ML" is not what the vendor slide deck says. It says "AI." Same math, different word.

3. LLM extraction and summarisation. Pulling structured data out of inspection reports written as PDFs. Extracting relevant history from decades of scanned documents. Drafting narrative report sections from underlying integrity data. Summarising trend reports for management. This is where LLM technology genuinely earns its place in integrity work. The task is bounded, the output is reviewable, and the alternative is a senior engineer spending hours on writing that a well-scoped LLM handles in seconds. The critical constraint is that every LLM output is a draft, not a decision.

4. Agentic AI. Autonomous, multi-step decision-making across integrity workflows. This is where most vendor pitches live, and this is where integrity work says "not yet, and possibly not ever for the ranking layer." The workflows in integrity that could plausibly justify an agent are narrow, on the periphery, and worth deploying with extreme caution behind a human review layer.

Most integrity workflows sit in patterns 1 and 2. A meaningful minority sit in pattern 3. Almost nothing in the core integrity ranking flow sits in pattern 4. If a vendor's demo has a lot of pattern 4 in it and they are asking you to trust the output without a human review layer, ask them how their approach survives an API 581 audit.

Worked example: AI-assisted RBI

Here is what "AI in RBI" actually looks like when it is done properly. We do this on Enrise.

The RBI engine itself is deterministic. It uses whatever framework the operator has chosen, API 580 / 581, DNV, or a bespoke internal method, and it produces a risk score for every asset based on probability of failure, consequence, and inspection effectiveness. That score is the primary output. It is explainable, auditable, and reproducible. An engineer can trace it back to first principles.

Sitting alongside the primary score is an AI-assisted ranking layer. This layer looks at the same inspection history, the same operating condition data, and the same asset characteristics, and it proposes ranking adjustments. It does one specific job: it identifies patterns across similar assets that a human engineer might miss when working through hundreds of items in a portfolio. Its output is not a score. Its output is a prioritised list of assets whose RBI ranking might benefit from a closer look, with the reasoning attached.

The engineer reviewing the portfolio sees the RBI score, and they see the AI's suggested adjustments with the reasoning. They accept the AI's suggestion, they adjust it, or they override it. Every choice is logged with justification. Nothing hits the inspection plan without a human accepting it. The regulator can walk backwards from any inspection interval through the human decision, through the RBI score, through the AI suggestion, all the way back to first principles.

That is a defensible AI-assisted RBI methodology. It gets you the benefit of pattern recognition on large portfolios without abandoning the audit trail that makes integrity work work.

Where LLMs genuinely help integrity work

Two specific places, both in pattern 3.

Extracting structured data from unstructured inspection sources. Every operator has decades of inspection reports as PDFs, scanned Word documents, and handwritten forms. Loading that history into an integrity platform used to mean paying junior engineers to key it in. An LLM with proper prompting, running through Azure AI Document Intelligence and a structured extraction schema, does that job faster and more consistently, with a human review pass for low-confidence outputs. This is one of the highest-value AI applications in integrity today, and almost nobody talks about it because it is not exciting.

Drafting narrative report sections. RBI narrative reports, inspection summary reports, and management briefings are dominated by prose. A senior integrity engineer spends hours writing them. Most of what they write is not creative work, it is disciplined synthesis of the underlying data. An LLM that has access to the structured integrity record can draft those narrative sections in seconds, grounded in the actual data. The engineer becomes an editor and reviewer, not a writer. Their time redirects to actual engineering judgement.

Both of these work because they are bounded, because the output is always reviewed, and because the underlying data is the ground truth. Neither replaces the engineer. Both make the engineer meaningfully faster.

What NOT to buy

If a vendor pitch has any of these characteristics, walk away or ask hard questions.

"Autonomous" AI ranking of the RBI portfolio. If the demo shows an AI making inspection interval decisions with no human review layer, the vendor either does not understand integrity or they are hoping you do not. The regulator will ask, and the answer had better involve a named engineer.

A giant "AI platform" that treats integrity as one of many use cases. The RBI engine, the corrosion loops, the fatigue models, the framework compliance rules, these are not generic AI problems. If the platform did not start from an integrity foundation, it will not survive contact with a serious integrity engineer.

"Digital twin" language with no explanation of what the twin actually models. Digital twin is a real, useful concept in specific contexts, particularly pipeline behaviour modelling and structural response to load. It is also the most abused buzzword in this space. If the vendor cannot show you what physical process the twin models and what predictions it produces, they are selling a rendering, not a twin.

Chatbots that promise to "answer questions about your assets." Ninety percent of these are a search index dressed up with an LLM wrapper, hallucinating answers when the search misses. The narrow, useful version of this is a bounded question-answering system that only answers from a specific, versioned integrity record, refuses to speculate, and cites its sources. If the demo does not show refusal behaviour, it is not that.

No mention of how the vendor handles data residency. If the AI runs through an OpenAI endpoint outside your region, and you are a BNM-regulated or Petronas-adjacent operator, that is a procurement conversation you do not want to have. Azure OpenAI in a Malaysian or Singapore region is what regulated buyers should be asking about.

Where BlueAura and Optitech fit

We are not an AI vendor selling into oil and gas. We are an integrity platform built with an integrity consultancy, and the AI overlay is exactly as ambitious as the underlying discipline allows.

Enrise is the platform. PIMS, SIMS, and RBI in one integrated system, with the AI overlay doing the bounded, reviewable jobs above. Every AI output is explainable, auditable, and gated by a human integrity engineer. Every framework choice, API 580 / 581, DNV, ASME, is grounded in what integrity engineers actually use.

Optitech is the engineering partner. They bring integrity domain expertise, RBI methodology, and live project experience in Malaysia and Vietnam. On a typical engagement Optitech leads the integrity engineering baseline, and BlueAura builds and runs Enrise on top of it. You get a proper integrity consultancy and a proper AI-augmented platform in one engagement.

The delivery model is deliberately hybrid. If you want an integrity assessment led by engineers who have done the work before, Optitech does that. If you want a platform where the assessment lives, where it can be updated as new inspection data arrives, where the AI layer helps your engineers work through large portfolios faster, Enrise does that. If you want both together, the partnership is designed for exactly that outcome.

None of this is "AI for oil and gas" in the abstract. It is asset integrity done properly, with AI applied where it earns its place.

The recommendation

If you are an integrity manager evaluating what to do with AI right now, our honest suggestion is this.

Start with the boring pattern-3 applications. Extract your inspection history from PDFs. Let an LLM draft your narrative report sections against a structured record. Measure how much engineering time you get back. It will be substantial.

Add classical ML for anomaly detection on your inspection and sensor data, where you have enough historical data to train against. Measure precision and recall against real events. Adjust thresholds. This is well-understood work with real payoff.

Consider AI-assisted RBI ranking only when your underlying integrity record is clean, your framework is stable, and your engineers have bandwidth to review AI suggestions properly. Even then, keep the AI in the assistant seat, not the driver seat. Every ranked adjustment is a suggestion, not a decision.

Do not let a vendor talk you into an autonomous agentic RBI system. Not because the technology is bad, but because your regulator, your insurer, and your own HSE review process will make you regret it.

The bottom line

Asset integrity is not a normal AI use case. The regulatory and engineering constraints are real, and they exclude most of what vendors are pitching today. But there is a real, narrow, honest place for AI in this work: extraction from unstructured inspection sources, narrative report drafting, classical ML for anomaly detection, and human-reviewed AI-assisted RBI ranking. Nothing more. Nothing autonomous in the ranking chain.

Get those four right, keep the RBI engine deterministic, keep the engineer in the seat, and you build an AI capability that survives an audit and delivers real engineering value. Get them wrong, and you buy a demo that will embarrass you the first time a regulator asks what a specific inspection interval was based on.

BlueAura and Optitech build the first version. If your operation is somewhere on this journey, we would rather have the honest conversation with you than the shiny one.