Data Science and Engineering Analytics Technical Section

I received some interesting comments on a LinkedIn article about the need for AI Assurance when adopting AI solutions in the Oil & Gas industry. I thought some of these comments deserved a second article to clear up common misconceptions and challenge some widely accepted narratives that, in my experience, are simply false.

Here is my take on those comments:

The "Human-in-the-Loop" (HITL) Claim

Today, look at any vendor contract or board presentation about AI solutions, and you will see this phrase used to guarantee safety: Human-in-the-Loop (HITL). It has become our ultimate assurance statement.

But is it really a "Human-in-the-Loop" decision, or just the "Rubber Stamping" of an AI-recommended course of action?

By the time a recommendation reaches the human (e.g., the drilling engineer), the AI has already ingested data, weighted parameters, and ranked the options. In most cases, the human only sees the AI's final ranked conclusions. When operators are working under intense time pressure, with no direct visibility into the confidence intervals or data quality flags that produced those conclusions, the decision was already shaped by the AI before the human ever entered the process.

I am worried that without proper assurance, if an engineer under time pressure has to respond to a potential kick, and the AI system doesn't expose why it reached its conclusion or its confidence level, that engineer is not a "Human-in-the-Loop."

They are a "Liability-Shield-in-the-Loop." !!

The False Equivalency: Deterministic Software vs. AI Probabilistic Systems

Some commenters made a common argument: AI is essentially just another software tool, and the Oil & Gas industry has successfully managed software transitions before without needing specialized Assurance standards.

This argument relies on a fundamental misunderstanding of how probabilistic AI differs from traditional, physics-based deterministic software. It also severely underestimates the legal and cognitive risks AI introduces.

• Deterministic software operates on explicit, physics-based rules (e.g., thermodynamics, fluid dynamics). If you input the exact same data, you get the exact same result. If the software fails, you can trace the exact line of code or flawed equation that caused it. Furthermore, most of this software is built on established industry standards (API, ISO, ASME, ANSI), such as API 5C3 / ISO 10400 for Well Design software.
• AI/Machine Learning models are probabilistic. They do not calculate based on physics; they predict based on statistical correlations mapped across vast, multi-dimensional historical datasets. They are subject to data drift, hallucination, and edge-case failures that deterministic software simply is not.

The Oilfield Gold Rush & The Accountability Void

The AI Gold Rush has officially hit the oilfield, and almost every player is selling shovels. If you watch the market closely right now, nearly every major service company is racing to rebrand their legacy tools and services as "AI-Driven." It is a relentless push to capitalize on global AI hype, driven by the high-margin revenues these technologies promise.

I believe that the AI deployment hype in the Oil & Gas industry has drastically outpaced our industry's Accountability architecture.

Consider this scenario: An AI agent or model misclassifies a critical downhole signal, triggering a severe well control event on a Deepwater floater rig.

When the dust settles, where do you draw the line on AI liability? Who ultimately holds the blame?

1. The Vendor who designed, trained, and sold the model?
2. The Operator who integrated and deployed the technology?
3. The Engineer who trusted the AI model's ranked conclusion?

When "AI Things" Go Wrong

We aren't just talking about a software glitch that corrupts a spreadsheet. In our industry, an unassured AI failure can lead to a tragic loss of life, a catastrophic asset failure, or a multi-billion-dollar environmental disaster. Right now, our legal and operational frameworks are entirely unequipped for when these autonomous systems fail.

When "AI" goes wrong and the dust settles, where do you draw the line on #AI liability? Who ultimately responsible?

1. The Vendor who designed, trained, and sold the AI model?
2. The Operator who integrated and deployed the technology?
3. The Human Engineer who trusted the AI model's ranked conclusion?

Have we actually figured this out yet, or are we just collectively hoping it doesn't happen on our watch?

We need to stop treating AI as a shiny plug-and-play tool and start treating it as a risk engineering challenge.

What are your thoughts?

How is your organization drawing the line between AI assistance and engineering accountability?

------------------------------
Mohamed ALi HASSAN
AI & Digital Well Engineering Advisor
https://www.linkedin.com/in/mohamed28ali07hassan/

------------------------------

It has been interesting to watch the Digital Oilfield transformation over the last two decades and to see it end up where we are today, asking the question "When "AI" goes wrong and the dust settles, where do you draw the line on #AI liability?"

The answer is "It depends".  And it depends on a lot of things…

It depends on the problem that you are attempting to solve; the clarity to which the problem has been defined; the appropriateness of the AI solution that you have selected to the specific problem being addressed; the degree to which the solution will be implemented, maintained, and updated; the objectives, expectations, and support of the decision makers who chose the AI solution; the roles and responsibilities of the HITL; the AI governance structure and implementation; etc.

And of course, the end results depend on the quality, suitability, completeness, and accuracy of the data that you have to work with…

It's more complicated than most people think when it comes to getting it right. And AI is definitely not "one size fits all".

I agree that it comes down to problem definition and governance. When a model fails, the "blame game" usually points to the algorithm, but as you mentioned, the root cause could be before this: poor data suitability or misaligned operator expectations. 

Our industry needs a strong balance between 'AI adoption' and AI assurance.

Appreciate you sharing your perspective on this

Original Message:
Sent: 06-10-2026 07:12 AM
From: Thomas Funchess
Subject: The Hidden Risk Behind AI Adoption in Oil & Gas: Is It Really "Human-in-the-Loop (HITL)"?

It has been interesting to watch the Digital Oilfield transformation over the last two decades and to see it end up where we are today, asking the question "When "AI" goes wrong and the dust settles, where do you draw the line on #AI liability?"

The answer is "It depends".  And it depends on a lot of things…

It depends on the problem that you are attempting to solve; the clarity to which the problem has been defined; the appropriateness of the AI solution that you have selected to the specific problem being addressed; the degree to which the solution will be implemented, maintained, and updated; the objectives, expectations, and support of the decision makers who chose the AI solution; the roles and responsibilities of the HITL; the AI governance structure and implementation; etc.

And of course, the end results depend on the quality, suitability, completeness, and accuracy of the data that you have to work with…

It's more complicated than most people think when it comes to getting it right. And AI is definitely not "one size fits all".

Mohamed - this is the most honest framing of the HITL problem I've seen in this section, and I'm coming at it from the other side of the table: I build predictive AI systems for industrial operations, and everything you wrote is the standard I think vendors should be held to.

A few additions from the builder's seat:

"Liability-Shield-in-the-Loop" is exactly right, and it's a design failure, not a deployment failure. If the engineer can't see the confidence interval, the data-quality flags, and the reasons behind a ranked recommendation at the moment of decision, the vendor didn't build a decision-support system - they built a liability transfer mechanism. The fix has to be architected in, not bolted on: confidence and data-quality exposure as first-class outputs, and just as important, abstention as a first-class output. A system that is never allowed to say "I don't have enough signal quality to call this" will eventually rank-order garbage with a straight face, and the engineer wears it.

On the deterministic vs. probabilistic point - agreed, and I'd push it one step further. The answer isn't to pretend ML is deterministic; it's to wrap probabilistic cores inside deterministic, physics-bounded envelopes. The model can predict whatever the data supports, but its outputs get checked against hard physical constraints before a human ever sees them. That's how you get the adaptability of ML without surrendering the traceability our industry was built on.

On standards - the void is smaller than the thread suggests, but the adoption gap is enormous. DNV-RP-0671 (assurance of AI-enabled systems) exists. ISO/IEC 42001 gives us a certifiable AI management system. NIST's AI RMF gives us a risk vocabulary. DNV also produced a state-of-the-art report on responsible AI for the petroleum sector for the Norwegian regulator. The frameworks are on the shelf. What's missing is operators writing them into contracts and bid evaluations. The day RFPs start requiring DNV-RP-0671-style assurance cases and confidence-exposure requirements, the "AI-driven" rebrand crowd thins out overnight - because an assurance case is the one thing you can't retrofit onto a legacy tool with a new logo.

On your liability question - my view as a builder: the line should follow the evidence trail. If the vendor can't reproduce why the model ranked option A over option B on the day of the event, the vendor owns far more of that failure than today's contracts admit. Vendors who can't produce that trail shouldn't be selling into safety-critical workflows. Period.

You said it best: this is a risk engineering challenge. The vendors who treat assurance as the product - not a compliance checkbox - are the ones who deserve to be on a rig floor.

I'm doing patent-pending work in exactly this space (predictive analytics and real-time monitoring for industrial operations) and would genuinely value your perspective. Following you here and on LinkedIn.

-Justin Waterman

info@wellcomman.ai

------------------------------
Justin J. Waterman, PMP LEED AP BD+C
Waterman Consulting Services | WellCommand™ CEO & Inventor Houston, Texas 77070
------------------------------