Occidental Petroleum’s Chief AI Officer:
AI at Scale in the Physical World

Michael Krigsman: Occidental Petroleum runs hundreds of AI systems. Let's go behind the scenes with Patrick Bangert, the company's chief AI officer.

LLMs communicate, they do not decide

Patrick Bangert: AI covers machine learning, vision, LLMs, agentic, and multiple methods that are decades old, but we still use them profitably today. So let's say, for instance, I'm in the Permian, which is an oil field here in Texas where we are injecting CO2 gas. It's like a pincushion, if you will. So you have a single pincushion with many pins in it. Some of your pins are injector wells where the CO2 is injected into the subsurface, and many wells are producer wells where the oil and gas come out.

So I have to decide on a limited budget of CO2 that's available to me, how much do I inject in each one of dozens and dozens of these injector wells? And I can make that decision very rapidly in real time. But I need to do it 24/7 over the long term. My goal is to extract as much oil as possible, not from a single well, but from the aggregate of all the wells that are available to me.

However, I have to obey a large number of surface facility constraints because all this is very physical equipment. Some of it, you know, doesn't work all the time. So the system has to keep all that into account, and it's AI that manages all of that and produces effectively the set point. So that's an example for a combination of machine learning and optimization algorithms working together. The interface then to the human operator does contain some LLM bits, but LLMs don't make the critical decisions. They're communications relevant.

So it's multiple parts of AI working together that ultimately create a piece of software. So ultimately we're in the software business. We create a software program that has AI bits in it facing the human user to help them ultimately instantiate these decisions and make a good outcome.

Michael Krigsman: So you're using a variety of machine learning models and analytics, data-driven models to understand the data and interpret and make the decisions. But then you're using LLMs as the layer to take the results of those predictive models and interpret them for communication purposes to the operators. Did I understand that correctly?

Patrick Bangert: Yeah, the final layer, of course, includes other communication bits as well, diagrams, images, numbers, and so on. But yes, they also include pieces of text that are produced by LLMs.

Field conditions push computing to the edge

Michael Krigsman: We'll take questions in a moment. We have a bunch that are starting to come in, but I have to ask you, what are some of the unique engineering challenges of deploying these types of models at the edge in very bandwidth-constrained and harsh field environments? You're not working in a lab.

Patrick Bangert: That is correct. Yeah. So oil fields tend to be very spread out. We're talking about many, many square miles of territory. Some of them are located in harsh environments that are you know, hot in terms of temperature. In the Middle East, they're in deserts, so hot in the daytime, cold at nighttime. They're far away from urban areas, so you don't have mobile phone coverage in some of these areas. So yes, they're harsh environments.

You get, you know, winds blowing that carry sand that do, you know, mechanical damage to equipment in the field. So all of these things have to be taken into account. So of course, Oxy has installed, in addition to the edge devices you mentioned, networking equipment. In some cases, we're operating our own power distribution lines that have to be monitored. AI is responsible for that too, by the way. We fly drones over the power lines. And so the challenges are quite physical for a physical company.

And our IT department is excellent at making sure that the AI has the appropriate connectivity that we can get the data out. Sometimes though, we do use edge devices. In other words, there's a little computer in the field physically right next to the equipment that it's operating.

So in many cases, a pump at a well site will have what's called a well controller, which is an actual physical computer box right next to the pump itself that does the controlling in order to avoid having to transfer data across the internet and back in a live stream, which we couldn't do 24/7. So we have a fleet of these equipments operating.

Cleaning the data is the secret sauce

Michael Krigsman: Interestingly, we have a few questions about model training, and let me start with Arsalan Khan. On Twitter, X, and he says, how do you train this type of AI before it goes live into the real world?

Patrick Bangert: Training AI models is a large and very well-researched science that's been going on for decades. So some of these models, as we just mentioned, are machine learning models. So machine learning is much older than generative AI. So it got started in the 1940s. Right. So there's lots to say about that, but effectively what you do is you take the data from the past.

You first of all quality control that data to make sure that you've got data that actually represents nature as it is, as opposed to all sorts of artifacts that occurred because a sensor malfunctioned or a cable got cut or something like that. So you clean the data first.

Michael Krigsman: Right.

Patrick Bangert: Then you typically divide it into two bits, a larger bit, typically 70%, that you use as examples to show the algorithm, and the other 30% you withhold in order to do testing, blind testing later. And then in teaching the model, training the model, there are specific algorithms. These are computational recipes that are meant to do that. Basically, the idea is that you have an equation that says the output is a function of the inputs in a certain formula that has parameters.

And the algorithm basically tweaks the parameters until the output from the model matches as closely as possible the output that you have in your training dataset. So it's basically monkey see, monkey do kind of a thought process here, but you have to supply a large number of examples. I like to compare it a little bit to an intern. When you hire an intern at a company, you have a very smart individual willing to learn, lots of energy, but needs to be supplied with the subject matter expertise.

Now you provide that intern with examples, and eventually the intern has internalized these examples and can perform the duty of whatever job it is. AI is just like that.

Michael Krigsman: So drill down, maybe just give us some examples specifically in oil and gas or at Oxy, because I think what the questions are trying to get at are some of the specific challenges that you face in your environment, especially given the fact that you're dealing with physical systems and the safety and all of that, and you need accuracy.

Patrick Bangert: Absolutely. Accuracy is a prime requirement here. Training these systems in an oil and gas environment's not fundamentally different from training AI models anywhere else really. The primary challenge, certainly the challenge that eats up most of the hours of work for the AI team is cleansing the data. That's always the part of the work that, you know, people don't like to talk about because it's laborious and so on. But that's actually the most important one.

Because again, in a physical environment, you do end up producing a large proportion of data that is not good to learn from because of the physical challenges of things like sensors getting old or cables being cut or things of that nature. A good chunk of the data has to be excluded. So that's really the secret sauce, if you like. It's not high-tech, but that is in fact the secret sauce is cleansing your data.

Then of course, because we're largely modeling physical systems and we know physics and chemistry laws from science, we can have what are called physics-informed neural networks or physics-informed AI algorithms as such. So we can explicitly include certain bits that we know to be factual, from natural science. And then we have a hybrid approach where AI performs a part of the analysis and physics, deterministic physics performs another part that is very valuable, improves the accuracy and reliability a great deal. And then as a last piece of analysis, we have certain limitations.

So for instance, a pressure cannot be higher than X, it cannot be lower than Y, it cannot be changed more than such per hour and so on. So there's a number of engineering rules, hard rules that if the AI tries to do something other than that, it will be forbidden. So AI is right in the middle between all of these preprocessing steps I illustrated, and there's post-processing that puts guardrails around it so that we cannot perform an unsafe action.

Michael Krigsman: So, you have a strong emphasis then on those guardrails during the training process?

Patrick Bangert: Yes, yes, we absolutely have a very strong emphasis on that because, as I said, our models do have physical consequences, so we do have to protect them from that.

Michael Krigsman: Obviously, that is one of the primary differences between dealing with LLMs inside an office environment or a pure programming software development environment for tools that will ultimately be used by business people is you're controlling physical machines and the physical consequences, damage, injury, and so forth, could be very profound if mistakes are made.

Patrick Bangert: Right. We, of course, also have an office environment where we're doing all the things everybody else is doing.

Buy rather than build, run open weights

Michael Krigsman: Let's take some more questions, and I'm just going to take these in order, so we're going to kind of jump around topics. And I love the questions. This is from Michael Beelar from Globant, and I owe Michael a huge thank you because Michael is the person who introduced us. So, Michael Beelar from Globant, thank you very much! And he says, Patrick, knowing your pragmatic approach to AI adoption. How do you budget for SaaS licenses versus token usage at Oxy? Totally different topic than we were just on, but a really important one.

Patrick Bangert: There's the economics debate. Of course, it costs money to make AI systems. It costs money to run AI systems. But hopefully these AI systems will earn you more than they cost. So we have to analyze all of this from the economics point of view. Ultimately, the decision we take is partly based on the features that the software that we buy and license brings in comparison to other software. And the cost is then compared to what would we have to spend to recreate the features that we actually need.

So of course, commercial software always has features you don't need. So you have to subtract them out. Typically speaking, my opinion is that software that you can purchase doesn't only just exist, it also has been debugged by the company who made it in cooperation with a large number of other customers. That is something that an in-house development can never do because we will not have many, many other customers to help debug the software. We will have to do that on our own.

By definition, we will be much slower in doing that. So there is not only a financial cost in building in-house software, there is a cost in delay, in time and effort, in the mistakes that will be made while the bugs are still there. So unless it is a great deal more expensive to purchase, I would always err on the side of purchase rather than build, certainly where any infrastructure software is concerned.

Michael Krigsman: Do you want to just comment at all on the issue of token costs? Many of us who create agents, and especially folks who are doing this at scale, are finding their model and token costs are just going through the roof to an unsustainable level. Is that something that you address there at Oxy?

Patrick Bangert: First of all, the cost per token is something that is quickly evolving over time. So the cost for a token today may not be the cost for that token tomorrow. As soon as a new model version comes out, the token of the model previous goes down. So very, very tough to predict what the token cost will be tomorrow. Also, it differs based on where you buy that token, which cloud, which provider, what's your contract. There are various discounts that larger companies get.

So it's difficult to say what your token cost will be. There are also models that are so-called open weight or open source. These are models that you can download into either your on-premise ecosystem or your cloud ecosystem, and they do not have token costs at all. You are then just in quotes paying for the computational infrastructure slash the electricity of running these models. So there are multiple ways to address this problem. And they should be considered.

So Oxy, for example, does do a significant part of its LLM work with open weight models where we are not paying for tokens at all. And so our token cost is actually very modest. And in comparison to the revenue that we can generate with our AI applications, our costs are very interesting.

Michael Krigsman: So you're finding that the open weight models accomplish your goals and you don't need to rely on the latest and most expensive frontier models?

Patrick Bangert: Absolutely, yes. We are observing, and I'm hearing this from all of my fellow AI officers in other larger companies, two things. First of all, we are finding that the incremental quality improvement from one version to the next is currently very small indeed. In other words, the frontier models, even the last couple of versions of the frontier models, are good enough for real life. Even though they keep improving, the delta is not really making a big dent in real-life operations.

Secondly, the quality of the open weight models is absolutely comparable relative to everyday usage requirements. Yes, they are less good in the scientific metrics, but they're absolutely comparable in real-life experience.

Michael Krigsman: That's really interesting what you say about the quality of the results that you're getting from the open weight models. And folks, if you're interested in this topic of open source and open weight models, coming up on CXOTalk, we have the chief technology officer of Mozilla, the Mozilla Foundation, which creates Firefox, and we're going to be talking specifically about this. So, go to CXOTalk.com, subscribe to our newsletter, and you'll get an invite to participate in that live discussion.

So, we have another really interesting question from LinkedIn, and on this subject of models, from Swami Vaidyanathan. And Swami says, most of Oxy's AI runs on proprietary machine learning and computer vision models tuned to your specific operations. Frontier and open models are stress-tested by millions of users. How do you achieve the same validation confidence for proprietary models? And what does a model have to prove before you trust it in a live physical operation with high stakes?

Proprietary models win, vendors need scientific proof

Patrick Bangert: The proprietary models are trained on our data in order to run on our data. So they are intentionally niche for our environment very specifically, whereas these frontier models are trained, as you correctly said, on a huge host of data from the world. Now, that was trained on much more data, but that data to a very large degree is not relevant to our daily operations. So in actual experience, again, in our context, the frontier models are actually worse than our proprietarily trained models that are based on our specific trained context.

So I'll give a practical example. We have a lot of vision models running on our cameras, and for things that we have relatively few examples of, we are using vision language models, again, open weight models that are quite reasonable. They have accuracies in the 80% range plus. But if you have enough examples for your particular environment and you're able to train a convolutional neural network on your own data, you will achieve 99.9% accuracy without too much difficulty.

So you do get a significant bump in accuracy and therefore real-life profitability experience based on that if you do proprietary models. So if you have the data, and the people to train proprietary models, my recommendation is absolutely do that.

Michael Krigsman: Yeah, very interesting. The data and the people who have obviously the appropriate technical expertise in order to train those models properly.

Patrick Bangert: Yes.

Michael Krigsman: Let's go to another question. And this is from Adebanji Moronkeji, and he is a production and subsea engineer. And he wants to know, how can non-employees present their machine learning and computational fluid dynamics software to Oxy, especially in terms of sand production predictions? So I think what he's asking is, how can he sell this to Oxy? I think that's the question, although I'm not sure.

Patrick Bangert: On the receiving end, we are getting a lot of outreaches by a lot of different vendors of different models and software for all sorts of things. I do realize that for our potential vendors, it is a stressful and difficult experience to get a hold of us, I would beg for your understanding that it is likewise a stressful experience to be on the receipt of the outreaches, and we cannot have a detailed conversation with everyone due to volume.

But if you reach out to us with effectively some scientific basis for why your solution is better than other people's solution, we will take a look at that and then on the scientific merits evaluate whether we're going to go forward or not.

Michael Krigsman: So in other words, if you have a good solution, make your case and Oxy will evaluate it.

Patrick Bangert: Yes.

AI results still need human validation

Michael Krigsman: Chris Petersen says he's wondering if Oxy is building digital twins for exploration, extraction, or operation.

Patrick Bangert: Sometimes it means effectively a complete digital replica of the physical machine. That is actually very difficult to achieve. And in most instances, attempts to produce that kind of digital twin have technically failed. So we would first need to demonstrate that such a thing in fact exists. So a real twin is hard. We might be able to replicate, you know, certain bits of behavior of a piece of machinery or a piece of the subsurface. It is difficult. We would need to validate that based on historical data.

Again, the checking is similar to any other kind of AI system where you have a testing dataset that hopefully covers not just normal, but also various types of corner case operations and check whether that particular digital twin functions as it should.

Michael Krigsman: And, I will just mention that if you're interested in the topic of digital twins, I have interviewed on CXOTalk people from a number of different industries who are very focused on that. So, go to CXOTalk.com, and you can search for digital twin. For example, jet engines is a classic one, and we even interviewed somebody who is a physician or a scientist building a digital twin of the human heart. That's their goal. It's very early stages, of course. Okay. Let's go to another question.

Now, this one is a very broad question, and this is from Bridget Ejegi. And she says, and she's a Chartered Certified Accountant, and she says, is AI able to create new ideas based on what it has learned? It's a really, that's a good question.

Patrick Bangert: If you have a conversation with an LLM, it is a good and reasonable conversation partner, I think, to you on all sorts of fronts. And I think most of us have experienced that with some sort of an LLM system. It's debatable to what extent these ideas it gives you are new. But many of them are legit. Of course, you as the human have to evaluate to what extent these ideas are reasonable and whether or not you should take whatever decision it suggests.

That autonomy has to lie with you as the human. And of course, if you're doing it for a business, human in the loop and human decision-making and responsibility are very important. But I do think, yes, it is a legitimate conversation partner to surface ideas that you may not have had yourself.

Michael Krigsman: I use LLMs for that partner. But of course, it raises the question of what is a new idea? Because it's a new idea for you. If I'm using it as a conversation partner, it's a new idea for me. But the LLMs are ultimately based on this kind of reversion to the mean, summing up everything that it's read on the internet, every, all the data it can get its hands on. So it raises the question of how new the idea is in the broader global sense, as opposed to being a new idea for me.

Patrick Bangert: I think it is highly unlikely that an LLM would win a Nobel Prize for, you know, a new discovery. And we just saw this the other day, by the way, if I make a plug for what happened earlier this week. So AI solved, solved in quotes, one of the millennium challenges of mathematics. Now, as a mathematician myself, highly disappointed because the AI was able to provide a counterexample to whether or not the Navier-Stokes equation blows up on occasion. Yes, it does. Great. That in itself is not helpful.

What would've been helpful is a mathematical construction proof of how this counterexample came to be. And that intellectual investigation, that would've had a lot of value to mathematics as a whole. But of course, AI jumped to the result. It is a solution, but it's not the solution that we were all hoping for.

Michael Krigsman: It doesn't take away at all from the usefulness of, you know, the thing people think of AI as, being this driver of efficiency. Of course, it is. But, I think what is underplayed is the fact that the AI, as that conversation partner, has more knowledge than any one person can ever possibly have. That's really useful.

Patrick Bangert: Indeed, very useful. It's read the entire internet. It's read every published work, in human history, in every language, more than any of us could handle.

Scaling AI is a hardware problem

Michael Krigsman: Let's go on to the next question, which is Johnsie Michels. And Johnsie says, Patrick, as Oxy moves AI further into physical operations, computer vision, autonomous inspection, robotics, real-time optimization, and so on, where do you see the biggest gaps today between a successful AI model and actually deploying it at scale in the field? And where do you see partners like NVIDIA playing the biggest role?

Patrick Bangert: If we mainly look at scaling of AI models, then that the presumption is that we have a model in hand that is accurate enough for real life and all that, which in many cases we do. And then scaling that out is indeed more of a physical computation infrastructure challenge where we may have to procure a larger number of edge devices, transport them in the field, connect them to the network.

And then there are certainly networking challenges which are hardware related of making sure the signal travels from A to B to the cloud primarily. And then that would involve purchasing the edge devices for which a company like NVIDIA is absolutely relevant. And the fact that it always has manufacturing limitations since everybody wants to buy their chips and the manufacturing of these chips is limited, that certainly is a challenge. One of the big, big challenges in AI overall is can we create models that do not require a GPU to run?

If we can have such a model, it will be much cheaper to purchase the computational hardware to run that. It will consume less power. It'll be much easier to get ahold of because they're not as limited in the market as the GPUs are. So we are certainly making every effort to design our algorithms, especially the field ones that need to be scaled into the oil field, to not require a GPU. And most of the time we are successful at that.

Michael Krigsman: Let's take another question this time from Twitter, and it's Arsalan Khan again. And I'm jumping his question in before some of the others because he asked a technical question and maybe we can use this to kind of get a clearer understanding of some of these issues you were just describing. And then pretty soon I want to talk about the business case and the business aspects as opposed to focusing so heavily on the tech.

Arsalan says, given your size, do you buy AI-enabled hardware chips for your own infrastructure, or are you just using the AI software which might be available on the cloud somewhere?

Patrick Bangert: Are we purchasing some hardware ourselves? Yes, for the edge devices I mentioned, because those are edge devices, so we have to actually get real boxes. But if it doesn't have to run on the edge, we do make use of cloud, which is cloud infrastructure data centers ultimately. And yes, inside the cloud, we then also purchase software from other vendors, typically SaaS software, much of which comes from the cloud vendors directly.

Adoption is how the revenue KPI happens

Michael Krigsman: This is from Jason Chadee who says, what is your strategy to enable field ops end users to trust and use the deployed AI?

Patrick Bangert: It is critically important for any AI system to be adopted by its intended users. And so that goes under the umbrella of change management. So we really have two attitudes on change management. One is that we want to involve our stakeholders, which includes not only the end users, but a variety of other people, SMEs, the management, and so on. We want to involve all of those people as early as possible in a project, ideally before the project even begins, to hear all of their opinions.

What does the system need to perform when it's finished? How does it need to do that? What are the requirements and the restrictions and so on and so forth? And we take them on the journey to get to the finished product by involving them in all of our sprint meetings. So we use the agile project management methodology whereby the stakeholders meet every two weeks and see the incremental evolution of the product.

In other words, by the time we're done, our stakeholders, including our end users, will have co-created the final software outcome. And so they will be much more enthusiastic to use the product that they have co-created than if we came to them on some magic day and told them that here's a new thing to use. So that is critically important.

And then the second aspect to that is when it is finished, to provide comprehensive training to everybody who is supposed to use this tool so that they're not just willing to use it from before, but they're able to use it now. That it's ready. And that is absolutely in scope for any AI team anywhere to make sure that it gets adopted.

Michael Krigsman: In the pantheon of metrics, where does adoption lie? And also, what are some of the other metrics that you're using for evaluating these use cases?

Patrick Bangert: For most people, ultimately, it's an economics metric that leads to the decision of whether or not you'll do it. For us, revenue impact, in other words, increased oil and gas production is the primary one. Cost savings is a second, of course. Now we compute that on the assumption that people are going to actually use that tool.

And so adoption is not the number one metric that we use to decide on whether to do it, but adoption is the number one metric in order to enable the economic metric to actually take place. So if your application has the potential to have revenue impact X, that will only occur if you have full adoption for which you need to perform the kind of change management I referred to.

Michael Krigsman: Right. Very interesting. So the economic business case is the compelling argument and the channel through which that business case is recognized and utilized, that's adoption. Is that a correct way to understand it? Right.

Patrick Bangert: Adoption is the mechanism by which the revenue KPI is actually achieved.

Michael Krigsman: Yeah. Very interesting. I have not heard anybody describe it quite that way. It's a very, very clear way to do it.

Patrick Bangert: If no one uses your tool, you're not going to have any benefits.

Skip the pilot, commit on day one

Michael Krigsman: It's obvious once you say it. Okay. And this is from Saurabh Sapra, who says, most energy AI dies in the gap between a successful pilot and fleet-wide rollout across assets. At Oxy, what's the single biggest thing that separates a use case that actually scales from one that stays a This is the 95% experience throughout the economy, right?

Patrick Bangert: That effectively people get stuck in this process and there's a term for it. It's called pilot purgatory. Unfortunately, it's not my term. But this is basically the arena by which a pilot or a POC, as it's often called, is created. Okay. Between a vendor and a customer, and then they get stuck in this phase of doing the pilot. And I think this is fundamentally a mistake. So I often say, okay, what does the abbreviation POC stand for?

A lot of people think it's proof of concept, to which I say, I can validate your concept if we're actually talking about the concept, a scientific question, I can typically validate that in 10 minutes or less by Googling it because I will either find a scientific publication or a demonstration by a client, user, company that this has been done. So I can tell you that it can be done. The question is really, can you do it? So POC in my terminology stands for proof of competency, not proof of concept.

So the question is, can these people do it? Can that vendor do it? And that's the real question. And I think if people are honest about that with themselves, they will be able to conclude that POC project a lot sooner. Apart from that, the frequent problem is funding. Vendor companies and cloud companies alike are very quick to supply POCs for free or at a heavy, heavy discount and internally justify that to their management by saying, we'll make that money back once the client purchases the real thing.

However, the psychological understanding of the customer is we're getting a free gift. Let's take it. The intention often is not there to purchase the real thing later. And in most cases, in fact, that I've experienced also in my roles before Oxy, is that the decision-making management at the client side never hears about the pilot until the pilot is finished.

And then results are presented to management, and then the vendor shows up to these meetings expecting a final decision sign-off on the real project, whereas management is like, this is the first I've ever heard of it. So that's where the gap really is in pilot purgatory. And so in the best case, you're talking about waiting for the next budget cycle to get that decision in, which is never a happy moment. So I would encourage everybody to say, don't do pilots.

Get the funding, management buy-in, et cetera, et cetera, on day one and either engage in the entire thing or don't.

Michael Krigsman: It's a very confident approach. What you're describing requires a degree of confidence that I suspect many organizations experimenting with AI simply do not possess.

Patrick Bangert: That is true. When you're experimenting with AI, as you've just said, the critical question is, what are you experimenting with? The labor effort of the actual AI is an absolute minority. The thing you're actually experimenting with is the time of your employees to be trained, to go through change management, to go through the experience of learning new tools, of adopting it in the workplace, of seeing how it adjusts to the processes in the business and so on. It's adoption. That's the actual work here.

And that's why many pilots fail, because companies do not do the adoption work. And so that's the other downside. Pilots often don't succeed because they're not taken seriously by the business. They might be taken seriously by the AI department, but then it's academics convincing academics. What we really have to convince is the users, staff in the field. And if they're either left out or not taken along the journey, you will fail. That's even worse.

Michael Krigsman: If you are interested in this set of issues around pilots and pilot purgatory, go to CXOTalk.com and search for those terms because we have discussed this a lot with amazing people really in-depth on CXOTalk. There's a lot of information there, so go check that out. It's such an important topic. Thank you for the question. Here's a question from Unekwu Noel Abdullahi, and he says, would you mind, Patrick, sharing the kind of ROI that Oxy makes annually on its AI programs and investments? Is that something you can share?

If you cannot measure it, it's zero

Patrick Bangert: We do assess every use case on its economic impact. That's the primary criterion, as I said, the first one being revenue generation, the second being cost reduction. We do go through a careful analysis of that, and this is not performed by me or the AI department. It is performed by the business, and we do get formal sign-off on those numbers. So we're quite careful in assessing what the numbers are.

Then we go and execute the project, and we validate afterwards that this impact was in fact achieved, or whatever impact differs from that, and we have numbers on all of that. They're obviously not public, but we do go through the evaluation, and I would heavily encourage people to do that because you will be surprised, sometimes positively and sometimes not, what the estimates really are. Sometimes the impacts can be very significant, and that's fantastic. The third aspect I'd mention is that again, my personal opinion: if you cannot measure it, it's zero.

So you know, thinking that oh, the AI will approximately save so much time for so many people, that that's an academic discussion. It would be ideal if you could institute a real measurement in real time that would get saved to a database that you can have a dashboard for, that you can look in live.

You know, this month we've made this many barrels of oil, saved this much money, et cetera, you know, certifiably that you can, you know, take those numbers to your CFO and look at that, that is the real impact. I think, you know, looking also at, you know, my fellow chief AI officers that I communicate with, roughly speaking, in physical-based industries, if investment into AI is X, you can expect to make back on a year-on-year basis, probably somewhere around between 20 and 30 Xs.

Michael Krigsman: So again, for you, the proof is not in the theory. The proof is what's the actual benefit that is realized on the ground from the AI?

Patrick Bangert: Yes, absolutely.

AI fails for human reasons, not technology

Michael Krigsman: You have said that when AI fails, it is a human problem, not a technology problem. Can you explain this? I mean, we could talk for an hour on this, but just really briefly.

Patrick Bangert: In almost every case, failure is an economic failure. So failure to deliver value. Most of the time when AI systems fail to deliver their value, it is because either humans did not use it, could not use it, or it solved the problem nobody had.

Michael Krigsman: This is from Alain Siewe, who says, how much of the open weight decision is governance rather than cost? He's thinking about things like the ability to pin a checkpoint and reproduce an output for an audit years later versus a vendor that can deprecate a model underneath you.

Patrick Bangert: If it's an open weight model, you have the model in your hands, so you can institute even more checkpoints than any vendor with their model. So you're safe.

Michael Krigsman: What is the biggest mistake you see leaders make when bringing AI into an organization?

Patrick Bangert: Believing the hype that it's doable in days and believing the other hype that it will somehow get rid of all of us.

Michael Krigsman: You have to elaborate a little bit more on both of those. So the first one, the hype that,

Patrick Bangert: It's not doable in days. It takes months. And secondly, it will not get rid of all of us. It can be our secretary, our helper, our extension. It will make us more effective, but it will not get rid of us.

Michael Krigsman: So don't believe all the vendor hype. I don't want to put words in your mouth.

Patrick Bangert: Yes. Take the collective discussion on AI and separate it into the bucket that was originated by the tech bros who are personally financially vested in saying all this stuff and the bucket said by everybody else and believe the second bucket, please.

Michael Krigsman: Great advice! And, on the subject of CXOTalk shows on this topic, I am working on a show with a woman who works with many software vendors, and we're planning a show on how to see through vendor hype when it comes to AI, which I think will be really interesting. And, unfortunately, with that, we're out of time. Patrick Bangert is the chief AI officer of Occidental Petroleum. Patrick, thank you so much for taking your time to be with us. I'm so grateful to you.

Patrick Bangert: Thank you, Michael. Great to be with you.

Michael Krigsman: And, thank you to everybody who watched and the people who asked such great questions. And, I'm sorry we couldn't get to all of the questions. We have incredible shows that are coming up. I mean, really, really great ones. And, you folks who asked questions, I want you to go to CXOTalk.com, subscribe to our newsletter so we can invite you to upcoming shows so you can participate just as you did today. Huge thank you to Patrick and his team. Thanks, everybody, and I hope you have a great day!