AI is getting closer to the setpoint. Until recently, AI in industrial organizations mostly meant analytics on historian data or features in security tools. Now automation vendors offer copilots that generate control logic, plants run models that recommend process changes, and AI agents can call tools on their own. Each step moves AI closer to equipment that can hurt people or stop production when it misbehaves.
Four ways AI is entering OT
| Pattern | Example | Risk if it goes wrong |
|---|---|---|
| Advisory analytics | Predictive maintenance on historian data | Low to moderate: a bad recommendation is reviewed by people |
| Engineering copilots | Generating or explaining PLC code | Moderate: flawed logic can reach a controller if review is weak |
| Closed-loop optimisation | A model adjusting setpoints within limits | High: the model acts on the process directly |
| AI agents with tool access | An agent that can query and change systems | Highest: actions may be fast, chained and hard to predict |
The further down this table a use case sits, the stronger the controls around it need to be.
The principles agencies agreed
In December 2025, CISA and the Australian Signals Directorate's ACSC published Principles for the Secure Integration of Artificial Intelligence in Operational Technology, with the NSA's AI Security Center, the FBI, Canada's Cyber Centre, Germany's BSI, NCSC-NL, NCSC-NZ and the UK's NCSC. In short:
- Understand AI. Know its specific risks, train engineers and operators, and follow a secure lifecycle from design and procurement to maintenance.
- Consider AI use in the OT domain. Make a real business case, protect OT data, understand the vendor's role, and plan for integration problems such as latency and interoperability.
- Establish governance and assurance. Fold AI into existing security governance, test models continuously and track regulatory obligations.
- Embed oversight and failsafes. Keep humans in the loop, monitor AI behaviour, design for safe failure and include AI in incident response.
Design rules that follow
Turning those principles into engineering decisions:
- AI recommends, operators approve, unless a specific closed-loop use has been risk-assessed and bounded with hard limits.
- Safety systems never depend on AI. Safety instrumented systems and hardwired protections stay independent of any model.
- Fail to a known state. If the model is unavailable or behaves oddly, the process falls back to conventional control.
- Data leaves OT through the DMZ, in one direction where possible. Cloud AI services should not reach into control zones.
- Models are assets. Record them, their versions and their data sources in the asset inventory, and treat updates as changes under change management.
- Log what the AI saw and did. Inputs, outputs and approvals are evidence for investigations and audits.
Questions to ask before buying AI-enabled OT products
- Where is the model hosted, and what OT data leaves the site?
- Can AI features be switched off without affecting core functions?
- Can the AI write to controllers or change configurations, and how is that restricted?
- How are model updates tested, announced and rolled back?
- What happens on failure: does the product fail safe?
- Which logs are available, and can they feed your monitoring?
- How does the vendor handle vulnerabilities in the AI components?
The EU AI Act timeline after the 2026 omnibus
The EU AI Act treats AI systems used as safety components in the management and operation of critical infrastructure, including the supply of water, gas, heating and electricity, as high-risk (Annex III). The 2026 omnibus amendment, Regulation (EU) 2026/1744, changed the dates:
- 2 December 2027: obligations for Annex III high-risk systems, previously due in August 2026.
- 2 August 2028: obligations for high-risk AI embedded in regulated products under Annex I, such as machinery.
It also narrowed the definition of a safety component to AI whose intended purpose is preventing or mitigating risks to health and safety. Operators have more time, not less work: risk management, logging, human oversight and cybersecurity are still required. This is general information, not legal advice.
Fitting AI into IEC 62443
IEC 62443 does not need a separate AI framework to be useful. Place each AI component in a zone, document the conduits its data uses, include it in the risk assessment, and set a target security level like any other system. The zones and conduits method applies unchanged.
How OTVista helps
In OTVista, AI components are recorded like any other asset: in a zone, with their conduits, risks and owners. Governance holds your AI usage policy and approvals, and Risk Management keeps AI-specific scenarios next to the rest of your OT risks. If you prefer, a practitioner can run the assessment in the tool and help draft the policies and procedures for you.
Related reading: AI-assisted attacks on OT and AI in OT security: where it helps and where it needs guardrails.
Sources: CISA, ASD's ACSC and partners, "Principles for the Secure Integration of Artificial Intelligence in Operational Technology" (December 2025); Regulation (EU) 2024/1689 (AI Act), as amended by Regulation (EU) 2026/1744.
Topics: AI in OT, secure AI integration OT, CISA AI OT principles, EU AI Act critical infrastructure, AI Act omnibus 2026, industrial AI security