AI security for OT and industrial environments

AI is starting to appear in industrial settings for good reasons. It can help teams analyse alarms, summarise maintenance notes, support predictive maintenance, and speed up engineering tasks. In an OT environment, though, the security bar is different from a normal business application. The main concerns are not only confidentiality and integrity, but also availability, safety, and controlled change.

That changes how you should assess risk. A model that gives a wrong answer in a back-office workflow may be inconvenient. The same model, if it influences a setpoint, a maintenance decision, or an operator action, can create operational disruption or safety issues. For UK SMEs running plants, utilities, warehouses, or industrial services, the right approach is to treat AI as part of the control environment, not as a standalone IT feature.

Why AI changes the risk profile in OT and industrial settings

AI is being introduced into industrial operations in a few common ways. Some organisations use large language models to assist engineers with documentation, shift handover summaries, or troubleshooting. Others connect AI to historians, SCADA data, maintenance systems, or engineering workstations to detect anomalies or recommend actions. In more advanced cases, AI is linked to workflow tools that can create tickets, trigger maintenance tasks, or suggest control changes.

The problem is that industrial environments are built around predictable behaviour. OT systems often have long asset lifecycles, vendor-specific protocols, and strict change windows. AI systems are more dynamic. They may depend on cloud services, external APIs, changing prompts, retrained models, or retrieval from live documents. That introduces a wider attack surface and more uncertainty.

Availability matters more than in typical IT environments because downtime can stop production, affect service delivery, or create unsafe conditions. Safety matters because an incorrect recommendation can be acted on by a human or an automated workflow. And because many industrial environments have limited segmentation or legacy remote access patterns, the blast radius of a compromised AI integration can be larger than it first appears.

The main AI security risks in OT environments

One of the most important risks is data poisoning. If AI is trained or tuned on operational data, an attacker or careless insider can influence the output by inserting misleading records, manipulated maintenance notes, or false examples into the data set. Even without formal training, retrieval-augmented generation can be affected if the source documents are poisoned. The model may then produce unsafe or misleading guidance based on bad inputs.

Model tampering is another concern. If the model artefact, configuration, prompt template, or orchestration layer is changed without proper controls, the system may behave differently from what engineers expect. In industrial settings, that can mean altered thresholds, changed instructions, or a shift in how alerts are prioritised. The risk is not limited to the model itself. The surrounding pipeline, including prompt templates, connectors, and policy files, is often just as important.

Prompt injection is also relevant, especially where AI reads documents, emails, tickets, manuals, or web content and then acts on them. A malicious or compromised source can contain instructions that override the intended system behaviour. Indirect prompt injection is particularly important in retrieval workflows because the harmful instruction may be hidden inside a document that looks legitimate to a human reviewer. If the AI is allowed to call tools, the impact can extend beyond bad text output into actions such as creating tickets, querying systems, or changing records. For a deeper treatment of this class of issue, see our article on indirect prompt injection in RAG pipelines.

Shadow AI and unmanaged integrations create a quieter but very real risk. Engineers and operations staff may start using public AI tools to summarise logs, analyse alarms, or draft procedures. If that happens outside approved channels, sensitive operational data can leave the environment without review. Unmanaged connectors, browser extensions, and agent-style tools can also create hidden data flows that security teams do not see in normal asset inventories.

How AI systems interact with OT architecture

In practice, AI usually touches OT through a few specific points. Historians are common because they provide time-series data for analysis and reporting. SCADA and HMI environments may be used indirectly, for example when AI summarises alarms or suggests operator actions. MES platforms can be involved where production data is used to optimise scheduling or quality. Engineering workstations are another frequent touchpoint because they often hold configuration files, vendor tools, and maintenance artefacts that are attractive to AI assistants.

These touchpoints matter because they cross trust boundaries. An AI assistant that can read historian data but also has access to a ticketing system, file share, or remote command interface has more power than a simple analytics tool. If the same identity is used across multiple services, compromise in one place can spread quickly.

Cloud services and APIs add another layer of risk. Many AI products depend on external model endpoints, hosted vector databases, or SaaS workflow platforms. That means operational data may traverse networks and services outside the plant. Remote access paths also become more important. If an engineer can reach an AI tool through a VPN, remote desktop, or web portal, then the security of that path becomes part of the AI control surface. This is why industrial AI should be designed with the same discipline you would apply to remote maintenance access or privileged engineering tools.

Threat modelling AI in industrial environments

Threat modelling is the right place to start because it forces you to map what the AI can see, what it can change, and what happens if it behaves badly. STRIDE remains useful here, but it needs to be applied with OT assumptions. For example, spoofing may involve a fake maintenance source or a compromised connector rather than a simple stolen password. Tampering may affect prompts, source documents, model outputs, or downstream actions. Repudiation matters when you need to prove who approved a model-driven action. Information disclosure can include operational data, process parameters, or plant layouts. Denial of service may mean a model outage that blocks a workflow or overloads an operator. Elevation of privilege can occur if a low-trust AI component gains access to a high-trust control path.

A practical way to model this is to draw trust boundaries around four areas: data sources, model services, orchestration and tools, and control actions. Ask what enters each boundary, what leaves it, and what validation occurs at the crossing point. If the model reads from a document repository, what prevents a poisoned file from influencing the output? If the model can call a tool, what authorisation checks exist before the tool runs? If the model generates a recommendation for an operator, how is that recommendation reviewed before action is taken?

For industrial teams already using architecture methods, it can help to combine this with zone and conduit thinking. The same logic used in OT segmentation should apply to AI components. Keep high-trust systems separate from lower-trust data sources, and avoid giving AI direct reach into control functions unless there is a strong business case and a clear safety case. Our article on segmenting OT networks with the Purdue model and IEC 62443 zones is a useful companion when you are deciding where AI services should sit.

Practical controls to reduce AI risk in OT

Start with segmentation and identity. AI services should not sit on the same flat network as control systems. Place them in a constrained zone with tightly defined conduits to historians, document stores, or workflow systems. Use least privilege for service accounts, API keys, and human users. Where possible, separate read-only analytics access from any path that can trigger action. Strong authentication, short-lived credentials, and conditional access are especially important for remote users and administrators.

Input validation matters even when the input is natural language or unstructured content. Treat prompts, retrieved documents, uploaded files, and API responses as untrusted. Validate file types, limit document sources, and strip active content where possible. For tool-using systems, define allow-listed actions and parameters rather than giving the model broad command capability. If the model can create a work order, for example, it should not also be able to approve it or change the asset record without a separate control.

Output handling is just as important. Do not let model output flow directly into control actions, scripts, or privileged workflows. For sensitive actions, require a human approval step. In OT, that approval should be meaningful, not ceremonial. The operator or engineer should see the source data, the recommendation, and the reason the system produced it. If the output is used in a ticket or report, label it clearly as AI-generated so it can be reviewed in context.

Logging and monitoring should cover prompts, retrieved sources, tool calls, model responses, user identity, and any downstream action taken. The goal is not to store everything forever, but to retain enough evidence to investigate abnormal behaviour. Look for repeated prompt patterns, unusual source access, unexpected tool invocation, large bursts of queries, or model outputs that diverge from normal operational language. If you already have a SIEM, feed AI events into it alongside identity and network telemetry so you can correlate activity across layers.

For teams building secure AI controls, it is also worth aligning the engineering process with secure development practices. Our article on secure development practices for AI systems covers the broader lifecycle view, while input validation, encoding, and output sanitisation techniques is relevant when AI outputs are passed into other systems.

Securing AI data flows and training inputs

Operational data is often more sensitive than teams realise. Even if it is not personal data, it can reveal production rates, maintenance patterns, equipment health, or process constraints. If that data is used for training, fine-tuning, or retrieval, it needs a clear handling model. Define which sources are approved, who can add new sources, and how changes are reviewed.

Where possible, keep training and tuning data separate from live operational systems. Use controlled export processes rather than ad hoc copying. If external documents are used for retrieval, scan them for malware, restrict who can publish them, and apply content review for high-risk sources. A poisoned maintenance manual or supplier note can be enough to distort model behaviour if the system trusts it blindly.

Versioning is important too. Keep track of which data set, prompt template, and model version were in use when a recommendation was made. Without that traceability, it becomes difficult to investigate incidents or explain why a model behaved in a certain way. For SMEs, this does not need to be a heavyweight MLOps programme. A simple but disciplined record of model version, data source, approval date, and deployment owner is a strong start.

Third-party and supplier considerations

Many industrial AI capabilities arrive through suppliers rather than in-house development. That can be helpful, but it also means you need to understand what the vendor is doing with your data, how their model is hosted, and what control you have over configuration and logging. Managed services, embedded AI features, and vendor-hosted copilots can all introduce dependencies that are not obvious at procurement stage.

Before deployment, ask practical questions. Where is the model hosted? Is customer data used for training, and if so, can that be disabled? What logs are available to customers? Can you restrict which users can query the model? Can you disable tool use, external browsing, or autonomous actions? How are updates tested, and how much notice is given before a model or policy change?

It is also worth checking the supplier’s incident handling and support model. If the AI service starts producing unsafe outputs or becomes unavailable, how quickly can it be isolated? Can you fall back to a manual process? Does the supplier support export of logs and configuration for investigation? These are not just commercial questions. They affect operational resilience.

For a structured view of supplier risk, our article on securing AI procurement and third-party models is a useful reference point, especially where the AI capability is embedded in a wider industrial platform.

Detection and response for AI-related incidents

AI incidents in OT often look like normal operational issues at first. A model may start producing inconsistent recommendations, a connector may begin querying unexpected sources, or a tool integration may trigger actions that do not match the operator’s intent. That is why detection needs to focus on behaviour as well as technical events.

Monitor for unusual prompt volume, repeated attempts to bypass guardrails, changes in source document access, and tool calls outside expected operating hours. Track who approved the model, who changed the prompt template, and who modified the source list. If the AI is connected to workflow systems, monitor for spikes in ticket creation, duplicate actions, or requests that do not match normal plant activity.

Containment should be designed in advance. In many cases, the safest response is to disable tool access first, then reduce the model to read-only or advisory mode while you investigate. If the model is influencing operator decisions, switch to manual review and preserve logs, prompts, and source documents. Avoid making emergency changes to the control environment unless you have a clear understanding of the impact. In OT, a controlled rollback is usually better than a hurried fix.

It helps to define an AI incident playbook that sits alongside your existing OT response procedures. Include roles for operations, engineering, security, and the supplier. Decide who can suspend the integration, who can approve a fallback process, and how evidence will be captured. If you already have incident response runbooks, extend them to cover model behaviour, prompt abuse, and unsafe tool use rather than creating a separate process from scratch.

A pragmatic rollout approach for UK SMEs

For most UK SMEs, the safest path is to start small. Choose low-risk use cases first, such as summarising maintenance notes or helping engineers search documentation, rather than anything that can influence control actions. Keep the first deployment read-only, with no direct path into OT commands or automated changes. Define the data sources, the users, the approval process, and the rollback plan before go-live.

Build governance into change management. Treat prompt templates, retrieval sources, model versions, and tool permissions as controlled configuration items. Review them when the plant changes, when a supplier updates a service, or when a new use case is proposed. If you already have an ISMS, this fits naturally into risk treatment, supplier management, and change control. If you are working towards stronger governance, the same discipline used in IEC 62443-4-1 secure product development lifecycle for OT vendors can be adapted to AI-enabled industrial systems.

The key point is that AI in OT should be introduced with boundaries, not enthusiasm alone. If you can explain what the system can see, what it can change, how it is monitored, and how it is shut down safely, you are in a much better position to use it well.

If you are planning an AI-enabled industrial project and want a practical view of the controls, governance, and supplier questions to address first, speak to a consultant.

Frequently asked questions

What are the top AI security risks in OT and industrial environments?

The main risks are poisoned data, tampered model or prompt configuration, prompt injection through documents or workflows, unmanaged integrations, and AI tools gaining more access than they should to operational systems.

How do you secure AI without affecting uptime or safety?

Start with low-risk, read-only use cases, keep AI in a segmented zone, restrict tool access, require human approval for sensitive actions, and monitor behaviour so you can disable the integration quickly if it becomes unsafe.