Some organisations are exploring AI-assisted engineering, predictive insights and automated risk assessments while still working through incomplete asset information, poorly understood connections and uncertainty about who owns what.

That creates a tension.

The ambition is understandable. There are real opportunities to reduce repetitive work, connect fragmented information and help people make better decisions.

But what does the new capability need from the environment around it?

And could AI help resolve some of the weaknesses we are concerned about?

Both questions matter. Telling organisations to “sort out the basics first” is only part of the answer.

AI is already part of the conversation

This is no longer limited to experimental tools outside the industrial supply chain.

Siemens and Rockwell offer AI assistance within automation engineering products. Honeywell’s Experion Operations Assistant supports control-room decision-making. Security platforms such as Indurex describe using AI to connect engineering, operational and cybersecurity information to improve context and risk prioritisation.

These applications perform different jobs and need different safeguards. A tool generating proposed code has a different role from one analysing process behaviour or recommending a security response.

The useful starting point is the particular problem we want to solve.

A risk assessment needs more than the documents

In my work, I’ve seen both the potential and the limitations of using AI to support OT cybersecurity risk assessments.

One of the challenges is that the inputs do not arrive as a complete, consistent dataset. They come through documents, diagrams, records and conversations, in different formats and with different levels of detail.

Some of the most important information comes verbally from people working with the systems. They understand how the operation behaves, what depends on what and where the practical constraints sit.

That understanding may never have been written down.

Sometimes it only emerges when someone asks a follow-up question.

A system’s documented purpose might be straightforward. Understanding the consequence of losing it may require a conversation with the engineer who supports it or the operator who depends on it.

Those details can change a risk judgement.

The quality of the assessment depends on how well that context is captured and interpreted. Practitioner input remains important for identifying gaps, challenging assumptions and judging operational consequences.

A well-structured assessment is not necessarily a well-supported assessment.

The missing information may be in someone’s head

It is tempting to treat this as a data-format problem. Bring everything into a common structure and the assessment should improve.

That would help. But it does not resolve information that has never been captured.

A diagram might show a connection without explaining why it exists. An asset record might identify equipment without describing its operational significance. A documented workaround may say little about whether the next shift can actually use it.

Someone may know the answer. The assessment still needs to uncover it, understand it and consider how much confidence to place in it.

This is where experience matters. Knowing which answer needs challenging, where an explanation is incomplete and when another person needs to join the discussion.

An AI-generated conclusion needs to make those uncertainties visible. A lack of information should not quietly become an assumption that everything is satisfactory.

AI can help build that understanding

None of this means we should abandon the idea.

AI can help organise varied inputs, identify inconsistencies and suggest questions for further investigation. It can support the capture and structuring of knowledge that would otherwise remain scattered across documents and conversations.

Some AI-enabled tools also aim to connect engineering information, process behaviour and security events, helping teams understand possible consequences and prioritise investigation.

That is more valuable than simply producing a report faster.

Used appropriately, these capabilities could give practitioners more time to examine the difficult parts: conflicting information, uncertain dependencies and decisions with significant operational consequences.

The opportunity is to combine the tool’s ability to process information with the knowledge of people who understand the operation.

Requiring complete operational context before using technology that can help develop it would miss that opportunity.

Which foundations can it improve, and which does it depend on?

This is the distinction I would put at the centre of an adoption decision.

Incomplete asset context may be something an application helps improve. The absence of controlled access for connecting that application is a different problem.

Fragmented records may be an appropriate input to a bounded analysis. Uncertainty over where sensitive engineering information will be processed or retained needs resolving before those records are shared.

The requirements should follow the use case.

A tool analysing a controlled set of documents has a different relationship with the operation from one connected to live systems. An application recommending an investigation has different authority from one able to restrict access or change a configuration.

We do not need to solve every OT weakness before exploring AI. We do need to address the weaknesses that would make the proposed use unsafe, unreliable or difficult to govern.

A useful pilot should expose the limitations

A pilot should help establish where the application adds value and where people still need to intervene.

For the risk-assessment example, the useful question is not simply whether the tool can produce a convincing document.

Can it distinguish evidence from inference? Does it recognise missing information? Can a practitioner trace a conclusion back to its supporting material? What happens when two sources disagree?

Those questions help establish what the output can be used for.

The same thinking applies as a deployment grows. Additional data sources, permissions or automated actions can change the conditions under which the original pilot was assessed.

Moving from assistance to operational reliance needs a deliberate decision.

Readiness should support progress

AI has a useful role to play in OT, including helping organisations strengthen their understanding of their own environments.

Its adoption should start with a clear purpose and an honest view of the conditions around it.

What can it help us understand? What does it need to work effectively? Where must engineering and operational judgement remain central?

The aim is to improve the quality of the decision, not just the speed at which we produce an answer.

Before you commit to an AI-enabled OT tool or expand a pilot, understand what it will take to use it effectively in your environment.

OTIFYD brings engineering, operations and cybersecurity perspectives together to help you assess the opportunity, identify the gaps that matter and decide what needs addressing before deployment.

Have a use case or vendor proposal under consideration? Get in touch with OTIFYD to discuss your next step.

About the author

Serkan Yusuf is Director of Professional Services at OTIFYD, working with organisations to understand and manage cybersecurity risk across operational technology and industrial environments. OTIFYD helps organisations improve OT cybersecurity and operational resilience through practical, engineering-aware security services.