Representative End User Clients
Representative Automation Clients
Representative Software Clients
The third ARC Industry Leadership Forum Singapore brought together more than 200 industry professionals under the theme How AI Is Driving the Future of Industrial Operations and Supply Chain on August 27, 2026. Siemens participated as a Global Gold Sponsor. Alan Rantelino, Technology Business Development Manager for ASEAN, Digital Industries, Siemens, delivered a presentation titled Building a Defensible Architecture for Autonomous Industrial Operations.
Alan addressed an increasingly important question for industrial organizations: as artificial intelligence takes on a greater role in operational technology (OT), how can plants benefit from its capabilities while retaining control over physical operations?
The answer is not to depend entirely on the intelligence or trustworthiness of the AI model. Organizations need to engineer clear boundaries around what AI is permitted to reach, change, and override.
The full presentation can be viewed here or on YouTube:
AI Changes the Nature of Cyber Risk
AI investments can be associated with improvements in productivity, efficiency, quality, and reliability. Cybersecurity is often harder to justify because much of its value lies in preventing incidents and disruptions that may never become visible.
Yet cybersecurity becomes more important as AI moves beyond analysis and begins influencing physical operations.
In an IT environment, an incorrect software action may sometimes be addressed by restoring a file, rolling back an update, or restarting a system. In OT, that action may already have moved equipment, changed a process, disrupted production, or affected physical safety. The software may be restored, but the physical consequence cannot necessarily be reversed.
Several recent incidents involving AI-enabled cyber activity illustrate three broader changes in the risk:
AI increases the speed and scale of cyber activity. Thousands of actions may occur between a small number of human checkpoints. A person may remain in the loop, but that person is effectively sampling the activity rather than controlling every step. Defensive controls must therefore be able to detect and limit activity at machine speed.
Harm can emerge from harmless-looking actions. A harmful objective can be divided into smaller requests that appear legitimate when examined separately. Controls that evaluate only individual requests may miss the outcome produced when those actions are combined.
Digital actions can cross into physical operations. AI activity may move beyond its intended environment or find another path toward exposed operational systems. Containment must anticipate this possibility, while the final line of defense cannot depend on software alone.
The wider takeaway is that conventional human oversight may no longer be sufficient by itself. Effective control must account for the speed of AI activity, the combined effect of multiple actions, and the possibility that a digital decision could affect the physical plant.
Embedded Autonomy Complicates OT Cybersecurity
Autonomy is not limited to a future vision of self-operating plants. Robots already correct their paths, automated vehicles select routes and charging cycles, control loops adjust setpoints, and maintenance systems initiate work orders.
Alan framed the authority granted to these systems as a progression from observe to recommend, decide, and act. The further a system moves toward action, the more consequential an incorrect conclusion can become.
The cybersecurity challenge becomes more complex when intelligence is embedded inside devices, firmware, sensors, controllers, and control logic rather than deployed as a clearly identified AI application. An asset inventory may show that a device is connected without revealing the autonomous decisions it can make or what it has been authorized to change.
The concern is not limited to malicious or visibly malfunctioning systems. A trusted device could make an incorrect decision and communicate it with apparent confidence, while the process accepts and acts on that decision.
AI governance therefore cannot remain separate from day-to-day OT management. It needs to extend into asset inventory, procurement, firmware management, change management, and existing cybersecurity processes.
Visibility, however, is only the starting point. Even when an AI capability has been identified, organizations may not be able to fully verify its model or predict every decision it will make.
When the Model Cannot Be Verified, Engineer Its Authority
Conventional industrial equipment can be tested against defined specifications and operating limits. An AI model may behave differently depending on its training, available data, operating context, software updates, and the requests it receives.
This led to the central proposition of Alan’s presentation:
We may not fully verify every AI model, but we can engineer its authority.
The objective is not to prove that the model will always make the correct decision. The surrounding OT architecture must also limit the consequences of an incorrect or unexpected decision.
That architecture includes network boundaries, access controls, controllers, drives, interlocks, and independent safety systems. Together, these determine what an AI application can access, what it can change, and whether the plant can reject its request.
The closer AI gets to physical control, the tighter these boundaries should become. This is not an argument for either “AI everywhere” or “AI nowhere.” The authority granted should reflect the potential consequences of an incorrect action.
Three Tests of Architectural Control
The presentation used a layered OT reference architecture informed by established sources, including IEC 62443, NIST SP 800-82, IEC 61511, and CISA-led guidance on integrating AI into OT.
Across the architecture, nine controls limit what AI, software, and remote users can reach, change, and override. Alan summarized their purpose through three simplified architectural acts, each connected to a practical test.
Alan Rantelino outlined three practical tests for assessing control over the OT architecture.
Act 1: Keep It Out
AI applications and remote users should not have an unnecessary direct path from public or enterprise environments into the control system. Required connections should pass through appropriate security zones and controlled access points, with sessions authenticated and monitored before access to OT is permitted.
The test: Do you know exactly who and what is connected to the OT network, when it connects, and for what purpose?
Without this visibility, an organization cannot reliably control what is entering or interacting with the plant environment.
Act 2: Read More, Write Less
AI can create value by accessing operational information for monitoring, analysis, maintenance, and optimization. Permission to read plant data, however, should not automatically include permission to change the process.
Where write access is necessary, it should be explicitly engineered and limited to specific systems, variables, operating ranges, conditions, and periods of time.
The test: Do you know exactly what AI is allowed to change?
The issue is not simply whether write access exists, but whether that authority has been clearly defined and bounded.
Act 3: Make the Plant Refuse
Controllers, drives, interlocks, and other local components should retain limits that prevent the process from accepting an unsafe request. Independent safety systems should also maintain their own logic and route to a safe state rather than depending on the same AI to recognize the problem and initiate a shutdown.
The test: If AI makes the wrong call, can the plant still stop it without depending on that same AI?
AI may recommend, decide, or request an action, but the plant must retain the final authority to refuse it.
Together, these tests address visibility, bounded authority, and independent refusal. If the answer begins with “it should” or “I think,” the control may be documented but not sufficiently implemented or tested.
Deprivilege by Design
Safe AI adoption still depends on established OT foundations, including asset visibility, secure remote access, network segmentation, logging, change control, and independent safety systems. AI introduces new capabilities and risks, but it does not remove the need for these fundamental controls.
Alan’s message was not that industrial organizations should avoid AI or simply place less trust in it:
Trust is not an engineering control.
Autonomy should instead be engineered as bounded authority. AI should receive only the access required for its intended function, while the plant retains control over what it can reach, change, and override.
This is the principle behind deprivilege by design. No AI model should be able to grant itself greater authority, and a software update should not quietly expand its safe operating envelope.
The boundaries need to be designed before deployment. Technical success becomes operational success only when the plant retains the ability to reject an unsafe action.