OT/IT integration in manufacturing AI projects: 5 major risks and guardrail design
Connecting a factory's OT network to its office IT network for AI deployment is often the most dangerous step in the project. You bridge the entire IT attack surface directly into machines that cannot afford downtime. This article covers the five points where OT and IT most commonly fail when connected, and describes the guardrails needed during design, not the emergency responses needed afterward.
By
Tenten AI 交付團隊
產業交付
Published
November 21, 2025
Read time
6 分鐘
A manufacturing plant with decade-old PLCs and SCADA systems had an older industrial controller still running Windows 7. Recently, the company added an AI vision inspection system. The deployment team wanted to stream inspection data to the cloud for real-time model training. They asked: "Could you connect our networks for us?"
That question exposes the central problem.
OT (operational technology: the machinery and control systems on the factory floor) and IT (information technology: the corporate office network and cloud services) operate under opposing constraints. OT cannot stop running. An hour of production downtime can exceed an entire year's security budget. IT must continuously update, patch, and maintain connectivity to remain secure. When you connect these two networks to enable AI, you attach the IT attack surface to a system that cannot afford downtime. Security in OT/IT integration is not a firewall bolted on after deployment. It requires guardrails designed into the system beforehand. This article covers the five points where OT and IT integration most commonly fails.
Five major risks in OT/IT integration
The table below lists problems identified across multiple deployments. The left column describes each risk. The right column specifies the guardrails that must be designed before deployment, not applied as emergency patches afterward.
| Risk | Why It's Especially Critical at the OT/IT Boundary | Pre-Deployment Guardrail Design |
|---|---|---|
| Flat, unsegmented network | AI solutions often demand direct connections from production network segments to office networks; one infected laptop can move laterally straight to a PLC | Apply IEC 62443 zoning and conduit standards, place a DMZ between OT and IT, opening only necessary single-direction or controlled channels |
| Legacy systems that can't be patched | Windows 7, controllers with firmware that stopped updating, the moment they hit the network they're live targets, but you can't just reboot them for updates | Use virtual patching and network segmentation to contain them, rather than forcing upgrades that risk production shutdowns |
| The "read-only" assumption collapses | Most people think AI only reads production data, but model parameter write-backs and remote tuning become control channels | Clearly separate read-only telemetry from writable controls; writes need human approval and audit trails |
| Third-party and remote access spirals out of control | Equipment vendors and AI vendors each pull in their own VPNs and backdoors for maintenance, credentials get shared, nothing is logged | Define before deployment: minimum privileges, named accounts, time-limited connections, and session recording |
| No visibility or monitoring on the OT side | IT security tools can't read Modbus, OPC UA, and other industrial protocols, anomalies are a complete blind spot | Deploy passive monitoring that understands OT protocols; establish a baseline of normal traffic first, so you can actually detect what's abnormal |
Why emergency fixes don't work on the factory floor
In IT environments, when something breaks you isolate, reimage, and roll back. Production lines do not permit this approach. You cannot reboot an injection molding machine to install endpoint protection. You cannot tell a factory in peak season: "We need penetration testing next week, the line will be down." OT has maintenance windows only a few times per year, and each one competes with the production schedule.
In manufacturing, security is a design-time problem, not a repair-later problem. If guardrails are not built during the design phase, retrofitting them multiplies both cost and downtime several times over.
The method involves two steps before touching any AI system. First, map assets and data flows: which machines exist, what protocols they run, where data travels, who has write access. By the time this diagram is complete, approximately 80 percent of the risks become apparent. You discover that "just connect the networks" actually opens multiple paths that should not exist. Second, define trust boundaries: separate read-only telemetry from control commands and handle them with different network segments, different permissions, different levels of audit rigor.
AI deployment as a network redesign opportunity
Why integrate at all? Why pursue AI in manufacturing at this cost?
The opposite reasoning applies. AI deployment represents one of the rare moments when manufacturing can legitimately redesign OT/IT architecture. Normally, convincing factory management to stop production for network segmentation purely for security is extremely difficult. When the same action reduces defects measurably, suddenly budgets and maintenance windows become attainable. Build security as the foundation of an AI project, not as an obstacle to it.
At the same auto parts factory, the networks were not simply connected. A DMZ layer was added between OT and IT. AI inspection data traveled upward through a controlled one-way channel. Model parameter recommendations did not write directly to machines. Instead, they went to an interface requiring QA sign-off. The project added approximately three weeks to the timeline. The production line never stopped. Three months later, the actual usage rate of the AI inspection system, personnel on the floor genuinely consulting it daily, genuinely adjusting operations based on it, was above 90 percent.
Questions to answer before deployment
Is your production network still a single flat topology with your office network? Does this AI system only read data, or does it write control parameters back to machines? What accounts and channels do vendors use to access your systems, and is access logged? Do you have a current asset and data flow diagram? Most practically: how many maintenance windows do you get per year, and how much downtime can you actually afford for these protections?
Every question you cannot answer is a risk that will surface after deployment.
Engineering and security teams deploy together on manufacturing AI projects. Guardrail design and AI go-live become a single deliverable. Building a working demonstration is straightforward. Keeping a production line that cannot afford downtime both using the AI and operating securely requires integrated engineering from the start.
One stuck workflow
is enough to begin
Tell us what the team does today, where it breaks down, and what a better working day should look like.