The question of how to safely integrate artificial intelligence into operational technology environments has been debated in industrial security circles for several years without authoritative guidance from government bodies. That gap has now closed. A joint guidance document from CISA, the Australian Signals Directorate’s Australian Cyber Security Centre, and partner agencies from multiple countries establishes a framework for AI integration in OT environments that is specific, structured, and willing to draw clear lines.

The most important line it draws is this: large language models should not be making safety decisions in OT environments. The guidance is explicit that LLMs are inappropriate for safety-critical decision-making in industrial and infrastructure contexts, citing unpredictability and limited explainability as the key disqualifiers.

For organizations navigating vendor pitches for AI-powered industrial automation, predictive maintenance, and smart building optimization, this guidance provides a framework for evaluating what types of AI are appropriate for what types of operational contexts.

The Purdue Model Framework for AI Deployment

The most technically specific element of the guidance is its recommendation to differentiate AI deployment by Purdue Model layer. The Purdue Model — or ISA/IEC 62443 reference architecture — organizes industrial control system components into hierarchical levels from physical process equipment at Level 0 to enterprise IT at Level 5.

The guidance establishes distinct AI deployment recommendations for different operational levels:

Levels 0–3 (Field, Control, Operations): At the levels closest to physical processes — sensors, actuators, PLCs, SCADA — the guidance recommends predictive machine learning models for anomaly detection. This is the appropriate level for ML-based approaches because these models are deterministic, their decision logic can be inspected and validated, and their behavior is predictable given a defined input space. Predicting equipment failure based on vibration signatures, detecting anomalous process values, and identifying network traffic patterns inconsistent with normal operations are all within the appropriate use case for ML at these levels.

Levels 4–5 (Site Business, Enterprise): At the higher levels — enterprise manufacturing execution systems, ERP integration, enterprise data analytics — large language models and generative AI become appropriate. These levels deal with information rather than physical process control, and the consequences of an AI system making an incorrect or unpredictable decision are different in character. A misclassified maintenance work order is an operational problem; an LLM instructing a PLC to modify a safety setpoint is a different category of failure.

This layered approach provides a practical framework for organizations that are receiving vendor proposals for AI integration across the OT stack. The question to ask of any vendor proposal is: which Purdue Model level does this AI system interact with, and is the AI architecture appropriate for that level?

Why Not LLMs in Safety-Critical OT

The guidance’s explicit caution about LLM-first approaches for safety decisions in OT environments reflects a set of technical characteristics that make LLMs specifically unsuitable for this role.

Unpredictability. Large language models are probabilistic systems whose outputs can vary for identical inputs depending on internal state. This is acceptable behavior for a system generating marketing copy or summarizing a document. It is not acceptable for a system that is making decisions about industrial process control, where reproducibility and predictability are fundamental safety requirements.

Limited explainability. Safety-critical OT decisions require audit trails that can be reviewed by engineers, regulators, and incident investigators. When a safety system takes an action — opening a valve, triggering an alarm, initiating a shutdown — there must be a clear, inspectable record of why that action was taken. LLM reasoning is not directly inspectable in this way; the model’s internal processing cannot be traced back to a specific decision path that a human engineer can validate.

Sensitivity to adversarial inputs. LLMs are vulnerable to prompt injection and adversarial input techniques that are not applicable to traditional ML models or rule-based control systems. In OT environments where inputs may come from compromised sensors or manipulated data streams, this vulnerability class has direct safety implications.

Hallucination. LLMs generate plausible-sounding outputs that may not be accurate. In an information processing context, this requires editorial review. In a safety-critical control context, a hallucinated control recommendation could cause physical damage or endanger personnel.

Industry experts cited in the guidance used direct language about this risk: LLM-first approaches for OT safety decisions were characterized as inappropriate based on unpredictability and limited explainability as key concerns. This is not a hedged position — it is a clear technical judgment about the current state of the technology.

The Four Core Governance Principles

The guidance establishes four core principles for AI integration in OT environments:

1. Understand AI implications. Before deploying any AI system in an OT context, organizations should develop a clear understanding of what the AI system does, how it makes decisions, what its failure modes are, and what its behavior will be in edge cases and adversarial conditions. This understanding should be documented and validated, not assumed from vendor marketing materials.

2. Assess AI fit. Not every AI capability is appropriate for every OT context. The Purdue Model layer framework provides one dimension of this assessment; the nature of the decision being made provides another. AI systems that provide decision support to human operators are appropriate in contexts where the human remains the decision-maker. AI systems that make autonomous control decisions need significantly more scrutiny, validation, and constraints.

3. Establish governance with senior leadership accountability. AI deployment in OT environments should be a governance decision with explicit senior leadership ownership — not a technology decision delegated to engineering teams without executive visibility. The guidance specifically requires senior leadership accountability, reflecting the recognition that AI integration in safety-critical environments carries organizational risk that requires corresponding organizational oversight.

4. Embed oversight throughout the AI lifecycle. Deployment is not the end of governance. AI systems in OT environments require ongoing monitoring, periodic validation, and defined processes for identifying and responding to unexpected behavior. This includes monitoring for model drift, validating that AI system behavior remains within expected parameters as the operational environment changes, and maintaining human oversight capabilities even when AI is assisting or automating decisions.

Vendor Transparency Requirements

The guidance establishes requirements for AI vendors supplying OT environments that go beyond what most vendor contracts currently specify. Organizations using this guidance as a procurement framework have specific requirements to impose on their AI suppliers:

Software bill of materials for AI features. Vendors must provide transparent documentation of what AI components are in their products, including the underlying models, training data characteristics, and any third-party AI components embedded in the product. This requirement directly addresses the supply chain transparency gap that has made AI component security difficult to assess.

Data usage policies. Vendors must document how data from OT environments — process data, operational telemetry, sensor readings — is used by AI systems. This includes data residency requirements (where is the data processed and stored), encryption requirements (how is operational data protected in transit and at rest), and disclosure of any training use (whether operational data is used to train or improve the AI model).

Transparent AI feature documentation. Vendors should clearly document which product features use AI, how those features function, and what the observable indicators of AI-driven behavior are. The absence of this transparency makes it difficult for organizations to assess what their AI-enabled products are actually doing with operational data.

These requirements, taken together, reflect a recognition that the AI components in OT-adjacent products are often opaque in ways that traditional industrial control system components are not. An organization can inspect a PLC’s firmware and understand its logic; inspecting what an AI system is doing with process data requires deliberate vendor transparency that the market has not consistently provided.

Implications for Smart Office Deployments

Smart office environments occupy an interesting position relative to this guidance. Commercial building automation — HVAC control, lighting management, energy optimization, access control — operates at Purdue Model levels that the guidance characterizes as appropriate for ML-based anomaly detection but not LLM-based control.

AI-driven features in smart building platforms are increasingly common. Building management system vendors offer AI-powered energy optimization, predictive maintenance for HVAC equipment, and occupancy-based environmental control. The guidance provides a framework for evaluating these features:

Does the AI system make autonomous control decisions, or does it provide recommendations to human operators? Autonomous control of building systems — adjusting temperature setpoints, activating or deactivating equipment, modifying access control rules — without human review requires the same scrutiny as OT process control.

What type of AI is being used? ML models for pattern recognition and anomaly detection in building telemetry are appropriate. LLM-based “intelligent” building management that makes operational decisions through generative AI reasoning is not, under the guidance framework.

What transparency does the vendor provide? Smart building vendors offering AI-powered features should be able to provide documentation of the AI components used, the data those components process, and the decision logic they apply — consistent with the transparency requirements the guidance establishes for OT vendors generally.

Using the Guidance

The CISA/ASD joint AI-in-OT guidance is the clearest authoritative framework currently available for organizations working through AI integration decisions in industrial and building automation contexts. Its practical value lies in providing:

  • A principled basis for pushing back on vendor proposals that apply inappropriate AI architectures to safety-critical functions
  • A governance framework that assigns explicit senior leadership accountability for AI deployment decisions in OT
  • Vendor requirements that can be incorporated into procurement and contract terms
  • A layered deployment model that differentiates appropriate AI use by operational level

Organizations that have been navigating AI integration decisions in OT environments without a clear framework now have one, with the authority of a joint advisory from multiple national cybersecurity agencies behind it. The guidance’s clear position on LLMs in safety-critical systems is the most immediately actionable element: it provides a specific, defensible technical basis for declining vendor proposals that apply LLMs to functions where that architecture is inappropriate.