BLUF: Keep AI out of the direct safety and control path. In operational technology (OT), an AI system can observe, classify, prioritise and recommend; it should not receive an unrestricted route to a PLC, safety instrumented system (SIS) or actuator. Put inference behind an OT DMZ, bind every identity to a narrow purpose, and make a named operator or a separately engineered safety function the authority that crosses into control.
This is not a claim that AI has no industrial value. It is the boundary that lets teams use it without turning a model error, prompt injection, unavailable cloud service or compromised credential into a physical command. CISA’s joint OT AI guidance explicitly frames AI integration as a safety, security and reliability problem; NIST SP 800-82 Rev. 3 describes the distinct performance, reliability and safety requirements of OT.
Start with three planes, not one integration
The useful architecture separates evidence from inference and both from control. The separation is architectural: distinct network paths, credentials, logging and failure behaviour—not three labels on the same service account.
Reference architecture: zone-and-conduit pattern
1. Observation plane — passive collectors read historian replicas, OPC UA read-only endpoints or approved telemetry brokers. They attach source asset, timestamp, quality flag, engineering unit and confidence to each record. No write-capable OT identity is present.
2. Inference plane — an AI service in the enterprise zone or a hardened plant service receives a minimised, allow-listed data product through the OT DMZ. It returns a recommendation plus evidence references, confidence and model/release ID. It cannot resolve control endpoints.
3. Safety/control plane — PLCs, SIS and actuators remain in their protected zone. An approval gateway translates an accepted recommendation into a constrained work order or a separately validated control action. Safety interlocks remain effective even when AI, network or gateway fails.
This follows the operational logic behind predictive-maintenance architecture: diagnose from governed evidence before changing the process. For incident workflows, the same boundary complements approval-gated remediation rather than replacing it.
Decision table: choose the authority boundary
| Use case | Allowed AI role | Crossing into OT | Required control |
|---|---|---|---|
| Condition anomaly | rank and explain | none | read-only data path; operator investigation |
| Maintenance planning | propose work order | CMMS only | planner approval; asset and evidence links |
| Setpoint optimisation | advise within envelope | no direct PLC/SIS write | engineer approval; independent hard limits |
| Bounded closed-loop action | only after safety case and validation | dedicated, narrow gateway | fixed allow-list, rate limit, independent interlock, rollback |
| Emergency shutdown | none as authority | never via AI | certified safety function and established operating procedure |
The control details that decide whether the diagram is real
Put an OT DMZ between enterprise/inference services and control zones. Treat it as a conduit with an explicit contract: source systems, destination systems, protocol, direction, data fields, retention and owner. Do not allow a generic “AI integration” network rule. NIST’s OT guidance is relevant precisely because OT systems interact with physical processes and have constraints that ordinary enterprise applications do not.
Give the inference service a workload identity with read scopes limited to approved data products. The identity must not be re-used by collectors, engineering workstations or the approval gateway. Rotate credentials, log token use and deny by default. A model’s tool configuration is also an authorization surface: an LLM should not discover a write tool merely because it can name an asset.
The approval gateway is a policy enforcement point, not a chat confirmation. It checks the asset, permitted action, operating envelope, approver role, two-person rule where needed, expiry, rate limit and a complete evidence record. It should issue a work order by default. Where bounded automation is justified, its interface must permit only predefined commands; natural-language output must never be interpreted as a control command.
Failure modes to design and test
Model hallucination or bad correlation: the recommendation cites an incorrect cause. Mitigation: display source evidence and uncertainty, require operator validation, and measure false-recommendation rate by asset class.
Prompt injection or poisoned operational data: untrusted text attempts to alter a recommendation or tool use. Mitigation: isolate retrieved content as data, strip tool authority from inference, and use allow-listed structured inputs. See the existing guidance on
Identity overreach: a service account intended for telemetry can write to a controller. Mitigation: separate identities per plane, enforce least privilege at protocol and network layers, and test denied writes.
Inference or network outage: a cloud dependency delays a decision. Mitigation: retain manual operating procedures, local alarms and deterministic safety functions; failure must degrade to a known safe workflow.
Automation creep: a recommendation becomes a direct action after incremental exceptions. Mitigation: version the authority matrix, require change review for every new action class and run rollback drills.
For retrieval-specific threats, keep documents and external signals outside the instruction channel; the practical pattern is detailed in treating retrieved documents as untrusted input.
A maturity model that does not skip evidence
Stage 0 is offline analysis using historical, de-identified or replicated data. Stage 1 is shadow inference: recommendations are logged but not shown to operators. Stage 2 is advisory: an operator sees evidence, confidence and a proposed action. Stage 3 is approval-gated execution through a narrow gateway. Stage 4, if ever appropriate, is bounded automation inside a separately engineered operating envelope with independent interlocks. Promotion requires measured benefit and a documented failure response; it is not earned by a persuasive demo.
What this does not solve
Segmentation and approvals do not establish functional-safety compliance, certify an AI model, or determine legal obligations. A safety case, sector requirements, machinery obligations, contracts and local operating procedures require the accountable engineering and legal functions. The BSI notes that the joint guidance aims to use AI without endangering availability, security or functional safety and calls for roles, continuous testing, monitoring and incident-response/safety processes. BSI’s notice on the joint guidance is a useful German starting point, not a substitute for that review.
A practical first workshop
Map one candidate use case from sensor to actuator. Record every data flow, identity, protocol, zone, model release, human decision and possible write path. Then attempt to prove that an AI credential cannot command a PLC or SIS, and that operators can work safely when inference is unavailable. That architecture review produces a prioritised control backlog before procurement or pilot scope expands.
Sources
CISA et al., Principles for the Secure Integration of AI in OT
NIST, SP 800-82 Rev. 3: Guide to OT Security
BSI, Künstliche Intelligenz sicher in Industriesteuerungen integrieren
