The 5 Things Your AI Rollout Will Struggle With
Individual AI vs. Enterprise AI
Your AI rollout is probably going well right now.
Adoption is climbing, people are genuinely faster, and the feedback from the team is good.
That is exactly the problem.
What you are seeing is real, but it is individual productivity, and individual productivity is the part you get for free. The thing that actually changes how a business runs sits one level above that, and reaching that is much more complicated.
What follows are the five things we consistently see companies struggle with when they try to make that jump.
These are not the generic warnings about hallucinations and data privacy that you have already read a dozen times. They are the ones that show up in asset-heavy operating businesses, where the answer AI hands back ends up inside an invoice, a nomination, or a decision that somebody has to defend later.
To keep it concrete, we will use a midstream gas plant as our running example, and one question that gets asked every single morning:
“How is our plant operating today?”
The part you get for free
Everyone reading this has used AI plenty of times by now.
You may not remember the details of the first time, but you probably remember the reaction, which was likely close to “wow”.
AI is an undeniably impressive technology. As Steve Jobs would have said, it just works. You throw some random question or task at it and it typically hands back a well crafted response, a code snippet, an image, or nowadays even runs a full workflow for you.
The chat interface is a big part of why. It encourages you to experiment, to test it, and ultimately to develop an intuition for it. It often encourages you with positive reinforcement (“great question, Steve”). In a work setting that often starts as simply as asking AI to explain something to you, we find an early use case we wrote in 2023 when ChatGPT was just taking off and called “Google Plus”. It expands quickly from there.
And you get all of this “for free”. Not literally free, of course, because AI compute is expensive (and getting more expensive). But once an organization has made the investment to get AI-enabled, that individual productivity gain shows up on its own, without any additional training or infrastructure, and it shows up very quickly.
It is a true step change, and it is absolutely worth having.
It is also where most rollouts quietly stop.
The second tier, where AI becomes something the enterprise depends on rather than something individuals happen to be good at, is a completely different problem. Below is where it tends to come apart.
1. You will mistake individual productivity for enterprise capability
Six months in, the numbers look great. Licenses are being used, people report real time savings, and a few teams have built genuinely clever workflows for themselves.
None of that - on its own - means the business has changed how it decides anything.
Individual gains are additive. Enterprise capability is structural. The first does not turn into the second on its own, and the early success can hide the fact that the structural work has not started yet.
What this looks like: five people can now get an answer to “how is our plant operating today” in about thirty seconds, and no two of those answers match.
2. Your most important information is not in a form AI can use
The operating record of the business lives in daily production reports, pig reports, trucking tickets, allocation statements, incident reports, and email threads.
AI can read any one of those beautifully. That is not the same as being able to answer a question that spans a year of them.
Until that information is extracted and stored in a structured way, every question is answered from whatever happens to be within reach at that moment, which is usually the most recent document rather than the most relevant one.
What this looks like: answering the plant question properly means pulling four separate reports, and all four of them arrive as PDFs and email attachments.
3. The same question will get different answers depending on who asks
This one deserves a closer look, because it is the failure that does the most damage.
Two people ask how the plant is operating today.
The first, who is less technical with their prompts, gets back: “The plant is running normally with no major issues reported.”
The second, who is more technical, asks the same question and gets: “Inlet is 82 MMscf/d, recovery is 91%, and residue is on spec.”
The second answer feels much better. It has numbers in it.
But neither answer is verifiable.
Where did 82 come from, and is that gross or net of fuel and flare? Is 91% ethane recovery or total liquid recovery? Is “on spec” coming from the online GC, and was that GC frozen this morning like it was last Tuesday?
Ask again tomorrow and the numbers may move for reasons nobody can reconstruct.
This is not the AI being broken. It is the AI being asked a question that the business itself has never defined a single answer to.
What this looks like: two confident answers, both defensible, neither reproducible.
4. Nobody owns the business logic
Most companies assume the AI platform or the implementation partner brings the business logic with them.
They do not. They bring access.
The actual calculation, the one your contracts, your counterparties, and your board depend on, is yours to define. Somebody has to decide what recovery means at this plant, which meter is authoritative, and how to handle the days when a value is missing or frozen. Codifying this (i.e. putting a number/formula in-place to define what “good” means) is harder than it sounds.
That work is unglamorous, it is nobody’s favorite project, and it is almost never assigned.
What this looks like: ask who owns the definition of recovery for this plant and every answer points at somebody else.
5. The last mile is IT, not AI
The pilot works. Everyone is impressed. Then it needs to run in production.
Production means identity and access control, network boundaries, a live connection to the historian and the accounting system, an audit trail, and somebody on the hook to support it at 2am.
That is where a surprising number of promising pilots stall out, or quietly revert to the spreadsheet the pilot was supposed to replace.
What this looks like: the demo answered the plant question perfectly using data someone exported in March (potentially in a sanitized, structured, and static way for a pilot test), and three months later it still cannot reach the historian on its own.
What all five have in common
Every one of these comes back to the same root cause.
There is no single authoritative answer sitting underneath the chat window.
When someone asks how the plant is operating, the AI is not retrieving the company’s answer, because the company does not have one written down anywhere. It is assembling a plausible answer out of whatever it can reach at that moment.
That is fine for an individual. It fails at the enterprise level for two reasons:
The process is slow and never fully automated, because a person has to keep prompting until the output looks right
More importantly, the process is not repeatable or reproducible, so the same question can produce a different answer tomorrow with no way to explain the difference
Mark Cuban has written about these same issues himself.
And the stakes are not academic.
Nobody actually makes a decision on “how is the plant operating today”. They make decisions on whether to reject ethane, whether a pig is going to make it through, and what this month’s margin looks like. Those answers become invoices, nominations, and commitments to counterparties.
A plausible answer is not the same as a right one.
A right answer you cannot reproduce tomorrow is not a business process.
What has to be true instead
Two things, and only one of them is new.
First, the critical business logic has to live outside the chat window.
One definition of recovery. One authoritative meter. One agreed way to handle a frozen GC. Written down, deterministic, tested, and owned by someone.
This is the familiar part. It is business as usual, or business as it used to be. Those processes get built the way they always were, and they get exposed through interfaces so other systems can call them consistently, most often through what are called APIs, or Application Programming Interfaces.
API’s enable systems to communicate with each other
Second, AI has to be able to reach that logic.
AI capability gets extended in roughly four ways, from the simplest and most limiting to the most capable:
Prompting and reusable prompt templates
Custom instructions and shared knowledge bases
Retrieval across company documents and data
Direct access to the company’s own algorithms and systems
The first three are individual level moves. They are useful, they can be shared across a team, and they will never make an enterprise critical answer reproducible.
Only the fourth does that, and today it is typically implemented through something called an MCP server, which is just a standard way of telling AI what your systems can do and how to call them. That standard will change, probably more than once. The requirement behind it will not.
What you get once that is in place is not really an AI benefit at all. It is the benefit of having a governed source of truth:
Consistency and reproducibility. The answer to “how is our plant operating today” is the same regardless of who asks or how they phrase it.
Reusability. The logic is built once and shared across teams and workflows, instead of being reinvented by every individual in their own chat window.
Control and trust. Access to sensitive processes and data runs through a defined interface rather than ad hoc prompting.
Scalability. New systems plug into the same standard, so capability compounds instead of restarting each time.
This is a domain problem, not a software problem
Here is the part that gets missed.
The hard piece is not the plumbing. Anyone can stand up an interface.
The hard piece is knowing what the right answer actually is, and being able to prove it.
Defining what recovery, plant margin, or liquid holdup means for a specific asset, under specific contracts, with specific meters, and then defending that number to a counterparty, is domain work. It requires people who have run these calculations, been wrong, and figured out why.
That is also what makes validation possible. If you have built the physics based and first principles models that describe what the system should be doing, you can tell when a number coming back is wrong. Without that, all you can say is that the answer sounded reasonable.
This is where the shape of the market matters. Broadly, companies looking for help today are choosing between AI platform providers, who give you access and tooling but have no basis to judge whether your recovery number is correct, and systems integrators, who will build you excellent pipes and leave the definitions to you. Both are doing exactly what they are good at. Neither is accountable for the answer.
The firms that can do both are rare, because it requires living in the domain and in the software at the same time.
At Pontem, we have been building that deterministic layer for years, for humans. Every model, calculator, and monitoring tool we have delivered to an engineering team is exactly the asset AI now needs in order to be useful inside an enterprise.
We are not learning a new business, the consumer just changed.
Same bridge, new user
Pontem was founded on December 30, 2022, one month to the day after a then unknown product called ChatGPT launched. We had not heard of it when we started.
What we did have was a conviction that the hard, technical problems that actually run an industry are best solved by domain experts working from real data.
That has not changed. Since day one, we have been in the business of bridging data and discipline, pairing the raw information that runs an industry with the expertise needed to turn it into better decisions.
For years we built that bridge for people.
Today we are building the same bridge for AI, giving these new systems controlled, repeatable access to the processes and data they need to be genuinely useful.
Same bridge. New user.







