AI in OT: The Standards Stack and Controls at the IT/OT Boundary
On October 23, 2026, IIoT World published a Q&A with Gary Tillery (Skkynet) and Matt Morris (EverLine) on integrating AI into plants without widening OT exposure. It yields a stack of standards and a set of verifiable controls.
On October 23, 2026, IIoT World published a Q&A drawn from the session "It Can't Happen to Me – Until It Does" at the Industrial AI Summit 2026. The speakers are Gary Tillery, CEO of Skkynet, and Matt Morris, VP Security and Resilience at EverLine. This is not news about an event or a study, but a collection of practitioner guidance. It should be read with the knowledge that the article is marked as sponsored by Skkynet ("editorially independent") and that the speakers work in this market.
No single standard covers AI on the factory floor
Tillery's central point is that a stack of standards is needed. The biggest gap concerns agentic and generative systems: current standards assume a bounded model, not a planner that autonomously chooses which tools to use. Tillery notes that he looked up the references after the panel and that the list is not exhaustive, so it should be treated as a starting point.
The areas cited:
- Interoperability and asset data: IEC 62541 (OPC UA) as the base layer, so that AI reads machine state rather than raw tags; IEC 63278 (Asset Administration Shell) and RAMI 4.0 for the digital representation of assets; MQTT with Sparkplug B for lightweight telemetry, without replacing OPC UA semantics for control-relevant data.
- Security and architecture: IEC 62443 for zones and conduits, least privilege and security levels, including for the AI path; IEC PAS 62443-1-6 for IIoT; NIST SP 800-82 Rev. 3 as OT guidance; IEC 62264/ISA-95 for the boundary between enterprise and control; ISO/IEC 27001 for corporate IT, but not as a substitute for 62443 on the plant network.
- Functional safety: safety functions remain under IEC 61508, 61511, 62061 or ISO 13849, and no model or remote tool should write through that path.
- AI governance: ISO/IEC 42001:2023 (certifiable management system), ISO/IEC 23894, 5338, 5259 and 22989 for risk, lifecycle, data quality and vocabulary; NIST AI RMF (AI 100-1) with the generative AI profile AI 600-1; the EU AI Act, where applicable, which classifies safety components and certain industrial uses as high-risk.
- Digital twin: ISO 23247 as the framework for manufacturing.
According to Tillery, the AI Act aligns with 42001 and with the separation of safety, but does not replace IEC 61508 or 62443. Other mappings, such as the crosswalk between NIST AI RMF and 42001, are likewise his own assessments and not independent verifications.
Design rules for AI
Tillery proposes three principles:
- treat AI as an advisor;
- no standing model credentials to PLCs or historians;
- tool calls go through a broker outside the prompt, with short-lived, task-bound credentials and an audit trail showing who delegated the action.
The IT/OT boundary according to Morris
Morris starts from a premise: if a single phishing click can reach OT, you have an architecture problem. The design should therefore assume IT is already compromised. The real bridges, he observes, are usually shared Active Directory, reused credentials, dual-homed engineering workstations and always-on vendor remote access.
The controls indicated:
- separate OT identity, no domain trust, no shared accounts;
- connectivity mediated by an IT/OT DMZ: data is pushed out and nothing initiates connections into OT;
- remote access through jump hosts, phishing-resistant MFA, session approval and recording, time-limited access;
- application allowlisting on HMIs and engineering workstations;
- OT-aware monitoring in the DMZ;
- verification of operational dependencies.
As an example of dependency, Morris cites Colonial Pipeline: the OT side had not been compromised, but it was shut down because billing and product tracking depended on IT.
How to prove the controls work
The suggested evidence:
- assume-breach tests starting from a compromised IT workstation, in a replica lab or maintenance windows, not blindly on production systems;
- attack-path analysis on the as-built configuration, not the network diagram;
- island-mode exercises that separate IT and OT for a defined period.
The proposed metrics are time to isolate, the percentage of conduits validated in the year, and the number of undocumented dependencies found.
What to do with it
For IT and plant managers, the value lies in the checklist and measurable metrics rather than in the list of standards, which remains one speaker's recollection. A practical first step is to map the real bridges between IT and OT, verify that no AI agent holds standing credentials, and set a target for isolation time to be measured in an exercise. Finally, note that this summary is based on the first part of the article; the section on the usefulness of a dedicated secure network was not considered.