A vendor rep stands in the conference room with a slick laptop and a promise. His AI vision system, he says, can read the part right off the line and push a pass-or-fail straight back to the controller so the bad parts get diverted automatically, no operator needed. He just needs one thing: a network cable from his cloud appliance into the cell where the PLC lives. The controls engineer in the back of the room, a quiet man named Sam who has run this plant's automation for fifteen years, asks one question that ends the meeting: "Where does that cable go after it leaves your box?" The rep does not have a clean answer, and Sam knows exactly why that matters. The cable the rep wants is not a productivity decision. It is a security decision. It connects a machine that can move steel, build pressure, and crush a hand to a network the plant cannot fully see, through a box whose insides nobody on the floor controls. The promise of the AI is real. So is the risk of the cable. This lesson is about why putting an AI model anywhere near the PLC (the Programmable Logic Controller, the rugged computer that actually runs the machine's logic and motion) is a security decision first and a productivity decision second, and how to think about it without drowning in acronym soup.

Why the Plant Floor Is Not the Office

The single most important idea in plant-floor security is that the floor and the office are two different worlds with two opposite priorities, and treating them the same is how plants get hurt.

IT is Information Technology: the email, the laptops, the file servers, the ERP system, the world the corporate help desk runs. OT is Operational Technology: the PLCs, the SCADA system in the control room (SCADA is Supervisory Control and Data Acquisition, the screens operators watch and the setpoints they push), the sensors, the drives, the robots, everything that touches the physical process. The cable Sam was asked about crosses from the AI vendor's world into the OT world, and that boundary is where the whole conversation lives.

The two worlds have opposite top priorities, and this is the part most AI vendors do not understand. IT optimizes for confidentiality first: keep the data secret, patch fast, reboot when needed, an outage is annoying but survivable. OT optimizes for availability and safety first: the line must keep running, and nothing can be allowed to make the machine hurt someone. In IT, you patch a server on Tuesday and reboot it. In OT, you cannot reboot the PLC that is running a 600-ton press in the middle of a stroke, and you often cannot patch it at all without a validation cycle that takes weeks, because a controls change on a regulated line can require requalifying the process. The IT instinct, "just push the update," is a dangerous instinct on the floor. A reboot in the office loses an email draft. A reboot on the floor can drop a load, scrap a batch, or injure an operator.

This is why the discipline has a famous model for keeping the two worlds layered and separated. The Purdue model (think of it as floors in a building, numbered from the office at the top down to the machine at the bottom) puts enterprise IT at the top levels, the plant control systems like SCADA in the middle, and the actual controllers and sensors at the lowest levels right next to the physical process. The whole point of the layering is that traffic from the office should not reach down and touch the controller directly. There are supposed to be doors, locks, and a guarded lobby (a controlled zone, often called a DMZ, a demilitarized zone, the buffer between the office network and the plant network) between the email server and the press. When the AI vendor asks for a cable straight into the cell, he is asking to skip the lobby and walk straight to the machine room. That is the security decision Sam was protecting.

On the floor, availability and safety beat confidentiality every time. An AI that can take down the line, or move it, is a safety decision wearing a productivity pitch.

The 78 Percent You Cannot See

Here is the fact that should govern every floor-AI decision in 2026, straight from the security research: 78% of OT networks lack centralized monitoring. Read that slowly. More than three out of four plants cannot, from one place, see what is actually talking to what on their plant-floor network. They do not have a single screen that shows every device, every connection, and every conversation happening in the OT environment. They are running blind below the office firewall.

This is not a knock on the people running those plants. It is the brownfield reality. Most plants run a 1990s PLC, a historian nobody has queried in years, and a control network that grew up one machine at a time over thirty years, with no one ever drawing a complete map. The result is a network nobody fully understands, full of devices nobody can fully enumerate, speaking protocols that were designed in an era when "security" meant a lock on the cabinet door.

Now connect that fact to AI, because the link is the whole lesson. You cannot secure what you cannot see, and you cannot safely bolt AI onto a plant you cannot see. The plant manager's instinct after the smart-factory tour is to add AI everywhere, fast. But adding an AI appliance to a network you cannot monitor does two dangerous things at once. First, it adds a new device, often with its own network connections back to a vendor cloud, to an environment where you already do not know what is talking to what. Second, it gives that device a reason to reach across the OT boundary, pulling sensor data out and, in the worst designs, pushing decisions back in. Every one of those connections is an attack path, and on a network with no centralized monitoring, an attack path nobody is watching.

Put a number on the stakes. A targeted attack or even an accidental misconfiguration that takes down a plant's OT network does not cost an email outage. On a line running, say, $40 million of throughput a year, a multi-day production stoppage runs into the hundreds of thousands of dollars in lost margin per day, plus the recovery, plus the customer fallout, plus, in the genuinely bad cases, a safety event with a human cost no spreadsheet captures. The asymmetry is the point: the AI vision system might save the plant tens of thousands a year in caught defects, and a single OT security incident enabled by its careless connection could cost ten times that in one bad week. The math only works if the connection is governed.

Why an AI Model Near the PLC Is a Special Kind of Risk

AI is not just another piece of software you drop on the network. It carries three properties that make it a distinctive security concern on the floor, and naming them is how you ask the right questions of any vendor.

First, AI wants data, and data lives in the OT zone. A vision model needs the camera feed; a predictive-maintenance model needs the historian tags; a quality model needs the process parameters from the PLC. All of that data originates below the OT boundary. So almost every floor-AI use case creates a reason to open a path from the AI system into the OT zone to pull data out. Even a read-only data pull is a connection, and a connection is an attack surface. The good news is that a read-only, one-way data path (often built with a data diode or a tightly controlled one-way gateway, meaning data can flow out to the AI but commands cannot flow back in) is far safer than a two-way link. The first design question is always: does this AI need to write anything back, or only read?

Second, AI that closes the loop can move the machine. The vendor's pitch, push pass-or-fail back to the controller, is the dangerous case. The moment an AI model's output can change what the machine does, automatically divert a part, adjust a setpoint, trip a stop, the AI has become part of the control system, and a control system that can move steel must meet the safety bar for control systems, not the convenience bar for office software. A model that hallucinates a torque spec in a document is an embarrassment. A model that mistakenly trips a stop on a running press, or fails to trip one when it should, is a safety incident. This is why the governing rule for L1 readers is blunt: keep AI advisory and out of direct control of anything that moves, unless it is properly governed by the same safety engineering that governs any other control function. A safety-critical control loop is not where AI goes first, and for most plants it is not where AI goes at all in the early years.

Third, AI often phones home. Many AI appliances, especially the slick cloud-connected ones, maintain a connection back to the vendor for model updates, telemetry, and remote support. That connection is convenient and it is also a door from the outside world into a box that sits inside your plant. When the vendor pushes a model update, what exactly changed, who approved it, and could that same channel be used by someone who is not the vendor? An AI model that silently updates itself is a model whose behavior can change without your knowledge, which is both a quality problem and a security problem. The plant that cannot see its own OT network certainly cannot see what a vendor's cloud is doing through a tunnel into that network.

Work the contrast with a concrete pair of designs. Design A: the vendor's cable runs from a cloud appliance straight into the cell, two-way, with the model pushing divert commands to the PLC and phoning home for updates on a connection nobody monitors. Design B: a camera captures images, an edge device on a segmented zone reads them, the AI runs there with no path to write to the PLC, an operator sees the pass-or-fail recommendation and makes the divert decision, and the only data leaving is a one-way feed of results to a dashboard, with model updates staged, reviewed, and applied on a controlled schedule. Design A and Design B can use the exact same AI model and deliver almost the same defect-catching value. One is a security incident waiting for a bad week. The other is governed. The model was never the question. The connection was.

The Questions That End the Vendor Meeting

You do not need to be a controls engineer or a security specialist to protect the plant in a vendor meeting. You need a short list of questions that force the design into the open, the same way Sam's one question did. Every floor professional should be able to ask these.

Does this AI need to write to the control system, or only read? If the answer is write, the conversation just became a safety and controls conversation, and the controls engineer and the safety lead belong in the room. Read-only is a far smaller decision than read-write, and most of the early value (catching defects, predicting failures, surfacing insights) can be captured read-only.

Where does the connection cross the OT boundary, and through what? Does the data flow through the controlled zone, the guarded lobby, or does the cable skip the lobby and run straight to the cell? If it skips the lobby, that is the meeting-ender. The path should go through the segmented, monitored boundary that already exists for that purpose, not around it.

Can the connection be one-way? If the AI only needs data out, can it be built so data can flow out but nothing can flow back in? A one-way path turns the worst-case attack from "take over the machine" into "lose a copy of some data," which is a survivable problem instead of a safety one.

Does the appliance phone home, and can we control or sever that? Who can reach into this box from outside, when, and how would we know? Can model updates be staged and reviewed rather than pushed silently? An appliance you cannot disconnect from the vendor cloud is an appliance the vendor can change without you.

If this box is compromised, what is the blast radius? Is it isolated in its own segment so that owning it gives an attacker access only to a camera feed, or is it sitting flat on the same network as every PLC in the plant? This is the segmentation question, and on a network where 78% lack centralized monitoring, segmentation is the difference between a contained incident and a plant-wide one.

Who owns this decision and who signs the record? When the customer audits the plant, "the vendor set it up that way" is not an answer. The plant owns the security posture of everything on its OT network, the vendor's box included. Accountability does not transfer with the purchase order. A named human on the plant side owns the connection, its risks, and its monitoring, the same way a named human owns every quality and maintenance decision AI touches.

Who Owns the Boundary, and Why It Is Everyone's Job

It would be comforting to file all of this under "that is IT's problem" or "that is the controls engineer's problem" and move on. That instinct is exactly how the bad cable gets plugged in. The OT boundary is a shared responsibility, and the AI era makes it everyone's job because AI projects now come from everywhere: a quality engineer wants a vision system, a reliability lead wants a predictive-maintenance appliance, a plant manager comes back from a conference wanting a chatbot wired to the historian. Every one of those is a request to put something new on or near the OT network, and the person making the request is often not the person who understands the boundary.

This is why the security conversation has to happen at the start of an AI project, not at the end. The most expensive time to discover that a vision system needs a two-way connection to the PLC, or that an appliance phones home through an unmonitored tunnel, is after it is installed and running and the line depends on it. The cheapest time is in the conference room, when the question "does this need to write to the control system, or only read?" still has the power to change the design. A read-only, segmented, monitored, advisory deployment designed in from the start costs a fraction of a two-way, flat, cloud-tunneled deployment ripped out and rebuilt after a near-miss.

Bring it back to the thinning crew, because that is the program's spine. The plant is short three maintenance techs, the best inspector retires in November, and the pressure to let AI do more, faster, with less human oversight is enormous. That pressure is exactly what pushes a plant toward the dangerous design: let the AI close the loop, skip the human, run the cable straight in, because there is nobody to spare for oversight. The discipline of this lesson is the counterweight. A thinner crew is a reason to be more careful about the boundary, not less, because a thinner crew has fewer eyes to catch a problem and a smaller margin to absorb an OT incident. AI on the floor should make a thin crew safer and more effective, never expose it to a plant-wide outage to save an operator's ten minutes at the divert station.

Sam ended the meeting with one question because he understood the asymmetry the vendor's pitch deck left out. The AI is a tool, and a good one. The cable is a decision, and a permanent one. The plant that learns to ask where the cable goes, before it is plugged in, gets the upside of the AI without betting the line on a connection nobody is watching. That is what it means to treat AI on the floor as a security decision first and a productivity decision second.

Key Takeaways

• The floor is not the office. IT optimizes for confidentiality and can patch and reboot; OT (the PLCs, SCADA, sensors, and drives that run the physical process) optimizes for availability and safety, where a reboot can drop a load or scrap a batch. Treating the two the same is how plants get hurt.
• The Purdue model layers the plant like floors in a building, with a guarded lobby (a controlled zone or DMZ) between the office network and the controllers. The danger sign in any AI pitch is a connection that skips the lobby and runs straight to the cell where the PLC lives.
• 78% of OT networks lack centralized monitoring. You cannot secure what you cannot see, and you cannot safely bolt AI onto a plant you cannot see. Every new AI appliance adds a device, and often a connection, to an environment you already do not fully understand.
• AI is a special risk for three reasons: it wants data that lives in the OT zone (so it opens a path inward), it can move the machine if it closes the loop (so it becomes a safety-critical control function), and it often phones home to a vendor cloud (a door from outside into your plant).
• The governing rule for L1: keep AI advisory and out of direct control of anything that moves, unless it is governed by the same safety engineering as any other control function. A safety-critical control loop is not where AI goes first. The first design question is always read-only versus read-write.
• Two designs with the same model can deliver the same defect-catching value while one is a governed read-only segmented advisory deployment and the other is a flat, two-way, cloud-tunneled incident waiting for a bad week. The model was never the question; the connection was.
• Carry the six meeting-ending questions: does it write or only read; where and through what does it cross the OT boundary; can it be one-way; does it phone home and can we control that; what is the blast radius if it is compromised; and who on the plant side owns and signs for the decision. Accountability does not transfer to the vendor.
• A thinner crew is a reason to be more careful about the boundary, not less. The security conversation belongs at the start of an AI project, in the conference room, when the question still has the power to change the design and a near-miss is still cheap to prevent.