Offline AI for OT networks means running the AI model on a machine you control, with no prompts, programs or drawings leaving the site. In practice that is a local model, served by a general tool such as Ollama, on an engineering workstation that is isolated from the internet.
For engineers on water treatment works, pumping networks and battery storage sites, that is often the only way AI assistance can be used with real project data. This article explains why, how to set it up, what to record, and where a web tool such as LADX fits and where it does not.
Why OT teams cannot paste code into a chatbot
A PLC program is a map of the plant. It holds network addresses, interlock logic, setpoints and alarm limits, and on a water network it may reveal how an asset fails safe. Many UK water and energy operators are assessed against the NCSC's Cyber Assessment Framework, which expects them to know where sensitive system information goes. Sending that file to a public AI service is hard to square with that.
In December 2025 the UK NCSC co-authored joint guidance with CISA, Canada's Cyber Centre and other partners on the secure integration of AI in operational technology. It sets out four principles: understand AI, consider AI use in the OT domain, establish governance and assurance, and embed safety and security practices. A local model on an isolated engineering workstation is one of the easier ways to meet them, because the AI never sits in the control path.
Setting up a local model on an isolated workstation, step by step
- Choose the machine. Use an engineering workstation in your engineering zone, not a server on the control network. The AI does not need to see a PLC to be useful.
- Pull the model while connected. Model weights run to gigabytes. Pull the model you want, with Ollama or a similar tool, on a connected build machine, then move it under your normal media control procedure. Ollama also offers cloud models; for an air-gapped set-up use local models only.
- Verify what you transfer. Check a published hash for the installer and the model files where one is given, and log the result.
- Leave updates off. On an isolated machine, download new versions elsewhere and transfer them through change control.
- Decide where outputs live. Keep prompts, drafts and accepted code in a project folder, so they fall under your backup and retention rules like any other engineering record.
Why a small local model needs checking
Local models are usually smaller than the large hosted ones, and on their own they make more mistakes in ladder logic. Treat every output as a draft: compile it with the vendor's tools, review it, simulate it and test it before it goes near a controller. In practice, the bigger constraint on a site laptop is memory and speed, so test response times on the actual hardware before rolling it out.
| AI-in-OT principle | How an isolated local model addresses it |
|---|---|
| Understand AI | Engineers treat output as a draft that must pass review and test |
| Consider AI use in the OT domain | AI stays in engineering, never in the control or safety path |
| Governance and assurance | Model, tool version and use recorded in change control |
| Embed safety and security | No network path from the workstation, no writes to live controllers |
What it does not do
An AI model does not connect to your controller and should not. Downloads, online edits and diagnostics stay in TIA Portal, Studio 5000 or the relevant vendor tool. A compiler proves code is valid, not that it is correct, so peer review and FAT still apply. Isolated does not mean exempt: the workstation still needs patching, access control and malware protection under your OT security policy, and the NCSC's operational technology guidance applies to it like any other engineering asset.
What is Ollama? Running Local LLMs Made Simple
IBM Technology
This video is hosted on YouTube. Playing it loads content from Google, which may set cookies.
Watch on YouTubeWhere LADX fits, and where it does not
LADX is web only and free. It has no desktop app, no offline mode and no local model support: its AI requests go from ladx.ai's server, so a model on your own machine cannot be used, and it cannot run inside an air gap. That makes it the wrong tool for client programs under strict data rules.
It suits the work around that: non-sensitive drafting, learning and checking on a connected machine. The ladder editor and simulator, converters, HMI builder and panel CAD run in the browser with no account, and chat needs a free account. Generated ladder goes through the editor's own validator and a seal-in check, Structured Text is compiled by the LADV compiler, and problems are listed beside the answer. Code that passes can be run on a Wartens LADV virtual PLC in the browser at ladx.ai/vplc; the virtual PLCs are not real time, not safety rated and cannot control machinery. On the free tier, the company running the free model may keep prompts and answers, so keep site data out. LADX never connects to a controller either.
Where this fits on UK water and energy projects
On a treatment works upgrade, a local model is useful for drafting function blocks, converting legacy logic to a readable form and producing first-draft documents, all without breaching the client's data rules. Our article on water SCADA cyber security and the NCSC CAF covers the wider design decisions. On battery storage sites the same applies to controller logic and SCADA screens; see our battery storage SCADA and controls service.
Wartens engineers PLC and SCADA software for UK water companies and their contractors through our automation engineering service, working within each client's security and engineering standards.
Next step
Write down the data rules for your site first, then pilot a local model on a non-production workstation. For learning and non-sensitive checking, try the tools at ladx.ai. If you need PLC or SCADA engineering delivered under strict data rules, contact our Milton Keynes team with your client's constraints.
