Artificial intelligence is becoming part of industrial automation. It is being used to monitor assets, support predictive maintenance, optimize processes, prioritize alarms and help operators interpret large volumes of operational data. These capabilities are valuable, but they also change the basis for trust. Traditional automation is usually built around deterministic logic, where defined conditions are expected to produce repeatable outputs. AI-enabled automation depends on data quality, model behavior, operating context, supplier components and human interpretation, all of which can change after deployment.
For industrial organizations, the practical question is not whether AI can improve automation performance. The question is whether suppliers, integrators and asset owners can produce sufficient evidence that an AI-enabled function remains secure, reliable, bounded and operationally defensible in the environment where it will be used. A model that performs well during development may respond differently when plant conditions change, when sensor data becomes incomplete or stale, when a supplier updates a component or when an operator begins to rely on recommendations without fully understanding their assumptions and limits.
AI expands the industrial attack surface
Industrial cybersecurity programs have long focused on protecting assets such as PLCs, DCSs, HMIs, engineering workstations, remote access paths and OT networks. These controls remain essential. However, AI-enabled automation adds dependencies that may not be visible in a conventional network view, including data pipelines, training environments, model repositories, inference services, cloud or edge platforms, supplier-maintained update paths and operator decision interfaces.
This broader attack surface means that operational harm may arise even when a controller has not been directly compromised. Corrupted historian data can distort a predictive maintenance model. Manipulated sensor values can shift recommendations during runtime. A compromised model artifact or supplier update path can affect downstream industrial behavior. Operator-facing recommendations can also create risk if they appear credible but are based on incomplete data, uncertain assumptions or conditions outside the validated operating range.
Why traditional security testing is not enough
Traditional OT cybersecurity testing is effective at identifying weaknesses in access control, segmentation, configuration, communications and system hardening. AI introduces additional assurance questions that depend on data validity, model behavior, inference context and operator interpretation. A system may satisfy important cybersecurity controls and still produce unsafe or misleading recommendations if model behavior drifts, confidence information is incomplete or operating conditions differ from those used during training and validation.
This distinction matters because AI failures may not look like traditional intrusions. An unsafe recommendation may result from stale data, abnormal process conditions, adversarial manipulation, excessive operator reliance or a supplier-introduced change. In each case, the consequence may appear in production quality, equipment reliability, safety margin, environmental performance or service continuity rather than in a conventional security alert.
Using ISA/IEC 62443 as the foundation
The ISA/IEC 62443 series provides a practical and effective foundation for extending industrial cybersecurity assurance to AI-enabled functions. Its concepts of risk assessment, zones and conduits, security levels, secure development, system security requirements, roles and lifecycle practices help organizations decide where AI components belong in the industrial automation and control system architecture. Data pipelines, inference services, model repositories, supplier-maintained components and operator interfaces should not be treated as external analytics infrastructure once they influence operational decisions but considered part of the IACS security architecture.
Applied in this way, ISA/IEC 62443 helps organizations identify trust boundaries, allocate controls, define supplier responsibilities and connect AI-enabled products to the risk posture of the operating environment. It does not remove the need for AI-specific validation, but it prevents AI from being evaluated outside the industrial cybersecurity architecture in which it will operate.
What AI security validation must add
Security validation for industrial AI should produce evidence that the function remains dependable in its intended operating context. That evidence should include architecture and control verification, operational behavior validation, adversarial testing and deployment assurance with continuous monitoring.
Architecture and control verification confirms that the AI-enabled function is represented within the IACS security architecture, including trust boundaries, data flows, access controls, update mechanisms, logging, model repositories, supplier dependencies and monitoring points. Operational behavior validation determines whether the function performs reliably under representative process conditions and whether uncertainty, assumptions and limitations are visible enough to support operator judgment. Adversarial testing examines whether corrupted data, manipulated inputs, abnormal process states, compromised artifacts or supplier-introduced changes can mislead or degrade the function. Deployment assurance then sustains the trust case by monitoring model drift, data quality, configuration changes, software updates, anomalous behavior and shifts in operator reliance.
Human oversight is also part of the control strategy where low-consequence advisory analytics may be governed through periodic review and monitoring and functions that can affect safety, production continuity, quality, compliance or critical infrastructure services require stronger evidence, clearer intervention paths, manual override, fallback behavior and authority to suspend or withdraw the function when outputs appear unsafe or uncertain.
Toward trustworthy autonomous operations
Autonomous operation should be treated as a staged transfer of operational authority rather than a feature that is enabled once the underlying AI capability appears mature. Advisory output, supervisory influence and autonomous action are different operating modes and should require different levels of evidence. Authority should expand only when the organization can show that the function remains dependable within defined operating conditions, that operators can understand and challenge its outputs, that fallback paths are available and that residual risk has been accepted by the appropriate decision makers.
The future of trustworthy industrial AI will not be defined by model sophistication alone. It will be defined by the ability of suppliers, integrators and asset owners to build and maintain a defensible trust case that connects security architecture, product assurance, operational validation, adversarial testing, deployed-system monitoring and human accountability. Organizations that make this evidence discipline part of procurement, commissioning, change management and operations will be better positioned to realize the benefits of AI while preserving the safety, resilience and confidence on which industrial automation depends.
