Table of contents
An asset integrity manager I spoke with recently sat down in front of his organisation's new AI assistant and asked it a simple question. When was a specific pump last inspected.
The answer came back in less than a second. Neatly formatted. Confidently worded. Wrong.
He spent the next forty minutes going through the EDMS, the maintenance system, and a SharePoint folder owned by a project team that closed in 2019. The actual inspection record existed. It was in the right system. It was even attached to a tag number. The problem was that the tag number on the equipment did not match the tag number on the inspection record, because the equipment had been re-tagged during a 2017 modification and the inspection record was filed under the old name. The AI had retrieved a record. It had retrieved the wrong record. And it had presented it with the same confidence it would have used if it had been right.
A few weeks later I heard a similar story from an operations director at a different organisation. He had asked the AI tool for a summary of the current maintenance backlog. The number that came back was three times higher than what he expected. Before he raised it as a problem, he asked his team to look at the underlying data. About two hundred of the open work orders had been raised against equipment that had been decommissioned during a 2021 turnaround. The work orders had never been closed because the equipment they referenced no longer existed and nobody had told the system. The AI had counted them. The summary was technically accurate. The summary was also operationally meaningless.
Neither of these failures had anything to do with the model.
The Wrong Diagnosis
The instinctive response to a confident wrong answer is to change the tool. Switch vendors. Upgrade the model. Add a wrapper. Buy something more specialised. Most of the AI procurement conversations happening in operating energy companies right now are framed in this way. The tool is not delivering. Therefore the tool must be wrong.
The tool is not wrong.
The tool is doing exactly what it was designed to do. It is taking the data it is given, applying a language model to that data, and producing an answer. If the data layer underneath is inconsistent, the model picks one version and presents it. The model is not in a position to know which version is current. It is not in a position to know that the same pump appears under three different names in three different systems. It is not in a position to know that a P&ID was superseded in 2024. It is not in a position to know that two hundred work orders refer to equipment that has been physically removed. None of that information is in the model. None of it can be put into the model. It lives in the structure of your asset data, or it does not live anywhere.
When the model gives a wrong answer, the failure has already happened. It happened years earlier, in the slow drift between systems, in the modifications that did not propagate, in the registers that were never reconciled. The model is the surface where the failure becomes visible. It is not the cause.
A Useful Comparison
Most people have now had the experience of typing something into ChatGPT and getting a poor response. The instinct is to rewrite the prompt. Same model, same input data, different framing, dramatically different output. The variable was not the model. The variable was the structure of what you fed into it.
In an operating energy asset, the equivalent of the prompt is the structure of your asset data. The reference designation system that tells the model what to call things. The document register that tells it where to look for engineering basis. The tag hierarchy that tells it how systems connect to subsystems. The link between the asset record and the document record. If those are inconsistent, the model will pick one version and answer with the confidence it always uses.
You cannot prompt your way out of a broken information structure. You can only fix the structure.
What Has Actually Changed
The asset register problem is decades old. The document register problem is decades old. The mismatch between the two has been a quiet drag on operations for as long as there have been operations. So why does it feel acute now.
Three things have shifted in the last two years.
The first is that AI tools are now answering questions that executives ask directly. For most of the history of asset data, the people who interacted with the data were analysts, engineers, and document controllers. They knew the data was inconsistent. They compensated for it without naming it. They produced reports that smoothed over the gaps because they understood the gaps. When an executive asked a question, the answer came through a human filter that quietly corrected for the things the systems got wrong. AI removes that filter. The executive now asks the system directly. The smoothing is gone.
The second is that confidence is now bundled with the answer. A spreadsheet gives you a number. A model gives you a number with a sentence of explanation in plain English. The sentence makes the number feel verified. It is not verified. It is generated. The verification step that experienced engineers used to do in their heads has been quietly removed from the interaction, and most users are not yet trained to put it back.
The third is that the cost of acting on a wrong answer is faster than it used to be. When the maintenance backlog summary was prepared by a planner who knew the asset base, an error would have been caught before it reached a decision. Now the decision can happen in the same conversation as the question. The loop between question and action has shortened. The structural problems that were tolerable when the loop was a week are no longer tolerable when the loop is ninety seconds.
The result is that information layer problems that have been quietly costing operators money for twenty years are now producing visible, named, confident wrong answers in front of senior leadership. The cost has not changed. The visibility has.
Your AI tool is not failing because it is the wrong tool. It is failing because the data layer underneath it cannot give it a consistent answer. The model is doing its job. The structure underneath it is not.
What We Are Seeing Right Now
We were recently approached by one of the largest wind turbine organisations in Europe. They have made a significant internal commitment to AI. The budget is committed. The team is in place. The use cases are mapped. They are not at the start of their AI journey. They are well into it.
What is interesting about the conversation is what they asked us to help with first.
Not the AI.
They want the information structure underneath it. They have made a deliberate choice to invest in process, in reference designation, in document discipline, in the basic plumbing, before they let the AI loose on it. The leadership team understands that running advanced tooling on top of an inconsistent data layer would produce confident, fluent, expensive nonsense, and that no amount of AI investment recovers from that starting position. They have decided to do the unglamorous work first. The AI investment will land on a foundation that can carry it.
This is not the common pattern. The common pattern is the opposite. Buy the tool first, discover the data problem second, spend the next two years quietly trying to fix the data problem with the AI budget. That sequence almost never works, because the data work has its own pace, its own discipline, and its own success criteria, and it cannot be done as a side project to an AI initiative.
The organisations getting genuine value from AI in operations are the ones who have either already done the structural work, or who have the discipline to do it first. The rest are spending money to discover what their information layer actually looks like, which is an expensive way to learn something they already suspected.
What AI Actually Needs to Work on an Operating Asset
Four things underpin every meaningful AI deployment in an industrial environment. None of them are glamorous. All of them are unavoidable.
The first is a consistent reference designation structure. Every piece of equipment needs one name, one identifier, one place in the hierarchy. When the same pump is called P-3401 in the asset register, 3401-PUMP-A in the EDMS, and PMP3401A in the maintenance system, no AI tool can reliably tell you anything about that pump. The model will retrieve whichever record matches its query best and present that record as the truth. You will not always know which one it picked. The fix is not technical. The fix is a reference designation system that is consistent across systems and is maintained as systems evolve.
The second is tag-aware document linking. Every document needs to be linked to the equipment it actually describes, and that link needs to survive modifications. When a pump is replaced, the documentation for the new pump needs to be linked to the same tag, and the old documentation needs to be moved out of current state. Most operators have years of documents linked to tags that no longer describe the equipment in the field. The AI cannot tell. It surfaces whatever document the link points to, including documents that describe equipment that has not existed since 2018.
The third is revision discipline during management of change. This is the single most common failure point in industrial AI. Equipment gets modified. Procedures get updated. The original P&ID never gets re-linked. The AI surfaces the original P&ID because it is the most heavily referenced document for that tag, and the answer it gives reflects the equipment as designed in 2008 rather than as installed in 2024. The model is not at fault. The link to the current revision was never created.
The fourth is reconciliation between your asset register and your document register. These two registers exist in every operator. They disagree more often than they agree. If your AI is drawing on both, you have a coin toss between two versions of reality every time it answers a question. The reconciliation is not a one-time data exercise. It is a governance process that has to be owned and maintained, because the two registers will drift apart again the moment governance stops.
These four things are unglamorous. They do not appear in any AI vendor's marketing material. They are also the only foundation on which any meaningful AI capability can be built.
A Short Comparison
| When the structure is broken | When the structure is in place |
|---|---|
| AI surfaces confident wrong answers | AI surfaces verifiable correct answers |
| Each query produces a coin toss across systems | Each query traces cleanly to a known record |
| Executive decisions are made on smoothed misinformation | Executive decisions are made on consistent data |
| AI investment fails to land its business case | AI investment compounds with each use case |
| The data team spends its time chasing the AI's errors | The data team spends its time extending capability |
| Confidence in the tool erodes within months | Confidence in the tool grows with adoption |
A Test You Can Run on Monday Morning
If you want to find out where your organisation actually sits on this, do this exercise.
Pick the three most critical assets in your most important facility. Ask your AI tool to list every modification made to those assets since 2020. Then take the answer to the people who actually maintain those assets and ask them whether the list is complete and correct.
If the answer is wrong, missing important modifications, or formatted with a confidence that does not match the underlying evidence, the model is not your problem.
Your underlying structure is.
The exercise is useful because it is concrete, because it takes less than a day, and because the result is binary. Either the answer matches what the people on the ground know, or it does not. If it does not, no model upgrade and no vendor change will fix it. You can switch tools every six months for the next five years. The underlying answer will not improve.
The good news is that the structural work is finite. It has a beginning, a middle, and an end. The bad news is that it cannot be done after you deploy the AI tool. It has to come first, or it has to happen in parallel with the AI deployment under its own ownership and its own budget. Either way, it has to happen.
Final Word
If your organisation is preparing to make a meaningful investment in AI for operations, asset integrity, or document management, the highest leverage thing you can do this quarter is look honestly at the layer underneath. Not the platform you have chosen. Not the use cases you have prioritised. The reference structure, the document discipline, the register reconciliation. The unglamorous part.
The organisations that will get value from AI in five years are the ones doing this work now. The ones that skip it will spend their AI budget on discovery rather than results. They will run their first three AI initiatives, get inconsistent answers, switch vendors twice, and end the cycle with a smaller AI budget and the same underlying problem they started with.
The wind turbine organisation we are working with understands this. They have made the choice to invest in the foundation first. The AI will land on something that can carry it. That is not the common pattern. It is the right pattern.
This is the work SøDera does. It starts with a two-week assessment that tells you where your structure actually sits, what it is costing you today, and what would need to happen to make any future AI investment pay back. The assessment is fixed price and fixed scope. There is no obligation to continue afterwards.
If you have already invested in AI tooling and the results are not landing the way the business case promised, the assessment is also the cheapest way to find out why. Better to know in two weeks than to spend two more years discovering it the slow way.
Stay informed
Get new insights in your inbox
When we publish a new article on RDS, document management, or asset data strategy, we will send it to you directly. No noise, no marketing. Just the article.
Unsubscribe any time. We do not share your email.