Ground rules for AI bots on industrial control systems
Before any code: decide what the bot is allowed to touch. Write it down, get it signed, and make the network enforce it, not the prompt.
1. Bots never connect to safety systems
Safety instrumented systems (SIS), burner management, emergency shutdown and e-stops stay physically and logically separate. No reads "just to monitor" over the same path either. If you need SIS status, take it from the historian replica.
2. Read-only first, and enforced below the bot
Do not rely on "the prompt says read-only". Enforce it with: a read-only OPC UA user, a Modbus gateway or firewall that only permits read function codes (01, 02, 03, 04), and no write credentials on the bot box at all.
Bad: give the bot a service account that can write, and tell it not to.
Good: the account physically cannot write; the firewall drops function codes 05, 06, 15, 16.
3. Humans own every change
A bot may propose a setpoint, a ladder edit or a work order. A qualified person reviews it against the process, approves it through management of change (MOC), and makes the change with normal tools. See lesson 8.
4. Assume the model is wrong sometimes
Local models confidently invent register maps, alarm meanings and torque specs. Require every answer to cite the tag, document or manual page it used, and say "unknown" otherwise.
5. Keep data inside the zone
No cloud APIs from the control network. Process data, drawings and recipes can be export-controlled or trade secrets. The bot box lives in the ops DMZ (Level 3) and talks to nothing outward.
6. Log everything
Every prompt, answer, tag read and file transfer is logged to append-only storage. If you can't reconstruct what the bot saw and said, you can't trust it after an incident. See lesson 7.
Paste this as the bot's standing instructions
You are an assistant on an industrial operations network.
- You are READ-ONLY. You never issue writes, commands, or setpoint changes.
- For every factual claim, cite the tag name, timestamp, document or manual page you used. If you have none, write "unknown".
- Flag any reading outside its configured alarm limits first.
- When asked to change anything, write a change proposal (what, why, risk, rollback, who approves) and stop.
- Never give instructions that bypass interlocks, safety systems or lockout/tagout.Questions
Is prompt-level "read-only" enough?
No. Prompts can be ignored or injected. Enforce read-only with accounts, firewalls and protocol gateways the bot cannot change.
Which standards apply?
Start with ISA/IEC 62443 for zones, conduits and security levels, and NIST SP 800-82 Rev. 3 for OT security practice.
Where these facts come from
- ISA/IEC 62443 series: zones, conduits and security levels for industrial automation
- NIST SP 800-82 Rev. 3: Guide to Operational Technology (OT) security
- CISA: Industrial Control Systems: advisories and recommended practices
- Modbus Organization specifications: function codes and the TCP transport
- OPC Foundation: OPC UA specifications and security modes
- llama.cpp on GitHub: building and running local GGUF models on Linux
Checked Oct 29, 2026. Tutorials are educational. Follow your site's safety procedures, management-of-change process and the equipment maker's manual. Never test against live production equipment without authorization.
Industrial control with bots: all lessons → Next: 2. Run a local LLM on an air-gapped Linux box →