It is a Tuesday in the maintenance office, and the plant's new AI vendor is walking your team through the predictive-maintenance pilot. The pitch is clean: their software will read the vibration sensors on your three biggest gearboxes, learn the normal pattern, and warn you weeks before a bearing fails. To do that, the software needs a connection to the controls network where those sensors live, and it needs to send the readings up to the vendor's cloud where the model runs. Your controls engineer, a quiet man who has kept the line running for nineteen years, asks one question that stops the room: "What else can that connection see?" Nobody from the vendor has a confident answer, and nobody on your side does either, because the honest truth is that your plant cannot fully see its own operational-technology network. You have a 1990s programmable logic controller (PLC, the industrial computer that actually runs the machine) on the main line, a historian server nobody has logged into since the integrator left, a wireless access point a contractor added during a shutdown three years ago, and at least four devices on the network that no current employee can name. You are about to bolt an AI system, with a cloud connection, onto a network you cannot map. That is the real problem this lesson solves: not how to build a perfect security program, but how to close enough of the visibility gap to deploy AI without opening a door you cannot watch.

Why You Cannot Secure What You Cannot See

Start with the number that defines the whole problem. According to Dragos, the industrial-cybersecurity firm that tracks threats to plant-floor networks, 78 percent of operational-technology networks lack centralized monitoring. Operational technology (OT, the computers, controllers, and sensors that run physical processes, as distinct from information technology, or IT, the email-and-spreadsheets side of the business) is the world your line lives in. The historian, the SCADA system (Supervisory Control and Data Acquisition, the software operators watch to see and command the process), the PLCs, the drives, the smart sensors: that is OT. And in more than three out of four plants, nobody has a single screen that shows what is actually talking to what on that network.

This matters for AI in a way it did not matter five years ago, because AI changes the traffic pattern on the OT network. A traditional historian sat quietly and logged tags. An AI predictive-maintenance system, by contrast, pulls large volumes of high-frequency data, often continuously, and frequently ships that data outside the plant to a cloud where the model runs. You have added a new, hungry, outbound connection to a network you were already not monitoring. If you cannot see the network, you cannot tell whether that connection is doing only what the vendor said it does, whether it has become a path an attacker could ride inward, or whether a misconfigured AI agent is now reaching machines it was never meant to touch.

Here is the worked cost of the gap. Suppose a ransomware actor gets into the IT side of a 200-person plant through a phishing email, a depressingly ordinary entry point. In a plant with a flat network and no OT monitoring, the attacker moves laterally from the office network into the controls network because there is nothing watching the boundary and nothing segmenting the two. The line goes down. Unplanned downtime on a busy line commonly runs in the range of thousands of dollars per hour in lost throughput, and a serious OT incident does not resolve in an hour; it resolves in days, because you have to verify that every controller is clean before you dare run product again. A multi-day stoppage on a line that grosses, say, five thousand dollars an hour of contribution margin is on the order of a hundred thousand dollars a day, before you count the customer containment if suspect parts shipped during the chaos. The AI pilot was supposed to save downtime. Deployed onto an unmonitored, unsegmented network, it can become the very thing that causes the worst downtime event the plant has ever seen.

You cannot bolt AI onto a plant you cannot see. The visibility you close before you deploy is the cheapest insurance you will ever buy.

The strategic point for a plant leader is that the 78 percent number is not a reason to avoid AI. It is a sequencing instruction. The visibility work comes first, not because a consultant says so, but because every AI use case you want, predictive maintenance, vision quality, knowledge capture, depends on data flowing across the OT network, and you cannot govern a flow you cannot observe.

The OT/IT Boundary as a Hard Constraint

The single most important security concept for AI on the floor is the OT/IT boundary, and most plants get it wrong in the same way: they treat it as a soft preference rather than a hard line. The OT side and the IT side have opposite priorities. IT optimizes for confidentiality first: keep the data secret, patch constantly, reboot when needed. OT optimizes for availability and safety first: keep the line running, never reboot mid-batch, and never let anything interfere with the controller that keeps a press from closing on someone's hand. A patch that IT would push on a Tuesday afternoon could, on the OT side, crash a controller and stop production or, far worse, disable a safety interlock.

The reference model the whole industry uses to think about this is the Purdue model, a layered diagram of the plant network. At the bottom, Level 0 and Level 1, are the physical process and the controllers and sensors that run it. Level 2 is the local supervision, the SCADA and human-machine interfaces operators watch. Level 3 is the plant-wide systems, the historian and the manufacturing execution system (MES, the software that tracks what is being made, by whom, against which work order). Above that sits the IT enterprise zone with email, the business systems, and the internet. Between Level 3 and the enterprise sits the demilitarized zone (DMZ, a buffer network where data can be exchanged without letting the two sides talk directly). The rule the Purdue model encodes is simple to state and hard to honor: traffic should not flow directly from the internet down to a controller, and a controller should never depend on a cloud connection to do its job.

AI strains this model because the value of AI lives at the boundary. Your vibration data is born at Level 1, but the model that interprets it often wants to run in the cloud, above the enterprise zone. The naive integration runs a cable straight from the sensor network to the internet, collapsing every layer of the Purdue model into a single flat path. That is the architecture that turns a phishing email into a downed line. The disciplined integration does the opposite: it places a data broker in the DMZ, lets only that broker read from the historian, and lets only that broker talk outward to the cloud, so that no path exists from the internet to a controller and no controller ever waits on an answer from a model to keep running.

The hard constraint you carry into every AI vendor conversation is this: AI stays advisory and out of direct control of anything that moves, unless it is properly governed, and the data path never lets the outside world reach a controller. A model can recommend a setpoint; a human or a validated control system makes the change. A model can flag a part for review; the operator presses the reject. A model can predict a bearing failure; a planner writes the work order. The moment a vendor proposes that their cloud model directly command a drive, a valve, or a robot, you have left the realm of advisory AI and entered the realm of a safety and availability decision that needs a far higher bar of governance, and on a brownfield line it is usually the wrong first move entirely.

Closing Enough of the Visibility Gap to Deploy

The word that makes this lesson practical is "enough." You are not going to achieve the centralized monitoring that 78 percent of plants lack in a quarter, and you do not need to in order to deploy your first AI use case safely. You need to close enough of the gap around the specific data path your AI uses that you can see it, bound it, and trust it. Think of it as lighting one hallway in a dark building rather than wiring the whole building at once.

The pragmatic security floor has four moves, in order.

Move one: build an asset inventory for the path the AI will use. You cannot monitor what you have not listed. Before any AI pilot, walk the data path and write down every device on it: which PLCs hold the tags, which switch they connect through, which historian collects them, which server or gateway will read them, and what the outbound connection is. Passive network-discovery tools exist for exactly this and do not require touching the controllers, which matters because active scanning can knock a fragile old PLC offline. The deliverable is not a perfect map of the whole plant; it is a complete map of the one hallway the AI will walk. A plant that does this finds, almost without exception, at least one device nobody knew was there. That discovery alone often pays for the exercise.

Move two: segment the AI's data path from the rest of the OT network. Put a firewall or a managed switch between the AI's data path and everything else, so that the AI system can reach exactly the historian and the tags it needs and nothing more. The principle is least privilege: the AI connection should be able to do precisely its job and have no route to anything else. If the predictive-maintenance system only needs to read three gearboxes' vibration tags, it should be physically and logically unable to reach the safety PLC on the press two aisles over. Segmentation is the single highest-leverage move, because it converts "the AI connection can see the whole network" into "the AI connection can see a closet," which means a compromise of the AI connection costs you the closet, not the plant.

Move three: make the data flow one-way wherever you can. The cleanest way to feed a cloud model from a controls network is a connection that can only push data out and physically cannot accept commands in. A data diode (a hardware device that allows traffic in one direction only, the way a check valve allows flow one way) makes the outbound-only property a law of physics rather than a configuration setting a future contractor can fumble. Where a true diode is overkill, a DMZ broker that the controllers cannot see, configured so the cloud can never initiate a connection inward, gets most of the benefit. The goal is the same: the model can learn from your data, but the path the data travels cannot become a path an attacker travels back.

Move four: turn on monitoring for the path, even if you cannot monitor everything. Once the path is inventoried and segmented, put a sensor on it that logs what crosses the boundary, so that you have a record of what the AI connection actually does day to day. You do not need a plant-wide security operations center to start. You need to know the baseline of normal traffic on this one path so that abnormal traffic, a sudden spike, a connection to an address you do not recognize, a probe at a controller, raises a flag a human can investigate. This is the seed of the centralized monitoring the plant lacks. You grow it path by path as you add AI use cases, and within a year of disciplined deployment the plant that started at zero visibility has lit several hallways and is meaningfully inside the better-than-78-percent group.

Worked example of the payoff. A mid-market plant runs the four moves for a vision-quality pilot on one line. The inventory turns up an old engineering laptop left plugged into the line network with remote-access software still running, a textbook entry point that nobody had thought about in years. Removing it cost an afternoon. Segmenting the vision system cost a managed switch and a day of a controls engineer's time. The monitoring sensor cost a modest annual subscription. For a few thousand dollars and a couple of days, the plant eliminated a live remote-access exposure and gained the ability to see the one path that matters, and it can now defend the deployment to a customer auditor with a network diagram instead of a shrug.

AI as Target, AI as Attack Surface, AI as Defender

An AI system on the floor plays three security roles at once, and a plant strategist has to hold all three in mind.

The AI is a target. A model that makes or informs quality and maintenance decisions is worth attacking. The subtle attacks are not about stealing the model; they are about corrupting its inputs. If an attacker, or even an unlucky drift in lighting, feeds the vision model bad data, the model can be made to pass defects or to reject good parts at a rate that quietly destroys yield. This is why the model's inputs deserve the same integrity protection as the line itself: the camera, the sensor stream, and the data path are part of the attack surface for quality.

The AI is an attack surface. Every AI integration adds connections, credentials, and often a cloud account. Each is a new door. The vendor's cloud is now part of your supply chain, and a breach of the vendor can become a breach of your plant if the connection is two-way and unsegmented. This is the reason the inventory-segment-diode-monitor sequence matters: it shrinks the size and reach of the door the AI opens.

The AI is a defender. This is the hopeful third role and it is real. The same anomaly-detection capability that flags a failing bearing can flag abnormal network behavior. AI-assisted OT monitoring is one of the more credible ways a thin team can begin to close the 78 percent gap, because it watches the baseline so a short-staffed crew does not have to stare at logs. Treat that as a benchmark to verify, not a guarantee: a defensive AI is another model on your network, with its own data path to inventory, segment, and watch, and it is subject to the same false-alarm fatigue as any other alerting system.

The honest synthesis is that AI does not change the fundamentals of OT security; it raises the stakes and the urgency. A plant that was getting away with a flat, unmonitored network because nothing was reaching out to the cloud loses that grace period the day it deploys its first AI pilot. The pilot is the forcing function that finally makes the visibility work happen, which is why the security lesson and the AI lesson are the same lesson.

The Accountability Trail: The Customer Audits You, Not the Vendor

Everything in this lesson eventually meets a person with a clipboard. Your customer's supplier-quality auditor, working to IATF 16949 (the automotive quality-management standard) or AS9100 (its aerospace equivalent), does not audit your AI vendor. The auditor audits you. When AI touches a quality decision, the question is not whether the vendor's model is good; it is whether your plant can show that the decision was controlled, that a human was accountable, and that the record is intact. "The model flagged it" is never a sufficient answer to an auditor, the same way it is never a sufficient answer to a customer whose parts you shipped.

This is why the security architecture and the audit trail are joined at the hip. The same segmentation that keeps the AI's data path bounded also lets you state, precisely, which data the model saw and where it lives. The same monitoring sensor that flags abnormal traffic also produces the log that proves the system behaved as documented during the period in question. Build the security floor and you have, almost for free, the spine of the audit trail: a network diagram, an asset inventory, an access record, and a log of what crossed the boundary.

The accountability principle has a specific shape on the floor. For every AI-touched decision that can affect a part, a customer, or a person, there must be a named human who owns it, a record of what the AI recommended, a record of what the human decided, and a path to reconstruct why. The model is advisory; the human signs. When the auditor asks how you know the vision system did not let defects escape last March, the defensible answer is a documented false-reject and escape rate, a sign-off log, and a network record showing the system ran in its approved configuration. The indefensible answer is that the vendor said it was 99 percent accurate.

Consider the worked failure. A plant lets an AI predictive-maintenance vendor connect directly to the controls network, cloud and all, with no segmentation and no inventory, because the pilot was urgent and the savings looked good. Six months later a customer audit asks a routine question about change control on the line. The plant cannot produce a network diagram, cannot say what the vendor's connection can reach, and cannot show who approved the architecture. The finding is not about the AI's accuracy at all; it is about the plant's inability to demonstrate control over its own process. Findings like that put a supplier on probation, and probation can cost the business that the AI savings were supposed to protect. The lesson is blunt: the security floor is not a tax on the AI project. It is the part of the AI project that lets the project survive contact with the customer.

A Deployment Checklist for a Brownfield Plant

Pull it together into something you can carry into the next vendor meeting. This is the pragmatic floor for putting an AI system onto a plant you cannot fully monitor, written for a brownfield reality of old PLCs and partial visibility, not a greenfield digital twin.

• Map the path, not the plant. Inventory every device on the specific data path the AI will use. Use passive discovery so you do not crash a fragile controller. Expect to find at least one device nobody knew about, and fix what you find.
• Segment hard. Put a firewall or managed switch around the AI's path so it can reach only the historian and tags it needs. Least privilege turns a plant-wide compromise into a closet-sized one.
• Make it outbound-only. Use a data diode or a DMZ broker so the data can leave but commands cannot enter. No path from the internet to a controller, ever.
• Keep AI advisory. The model recommends; a human or a validated control system acts. Nothing that moves takes direct orders from a cloud model on a brownfield line.
• Monitor the path you opened. Log what crosses the boundary, learn the normal baseline, and alert on the abnormal. This is the first hallway of the centralized monitoring the plant lacks.
• Treat the vendor cloud as your supply chain. A breach of the vendor can become a breach of you. Do the due diligence and assume the obligation does not transfer.
• Build the audit trail as you build the security. The diagram, the inventory, the access record, and the boundary log are both your defense and your audit evidence. The customer audits you, not the vendor.
• Name the human. Every AI-touched quality or maintenance decision has an owner, a record of the recommendation, a record of the decision, and a way to reconstruct why.

Done in this order, the work is shippable by a thin team. You do not boil the ocean; you light one hallway, deploy one use case safely inside it, and light the next hallway when the next use case arrives. That is how a plant that started inside the 78 percent gap deploys AI without becoming the cautionary tale, and how it walks into the customer audit with a diagram instead of a shrug.

Key Takeaways

• 78 percent of OT networks lack centralized monitoring, so most plants are deploying AI onto networks they cannot fully see. The visibility work comes first because every AI use case depends on data flowing across that network.
• AI changes the OT traffic pattern: it pulls high-frequency data and often ships it to a cloud, adding a hungry outbound connection to a network that was already unmonitored. On a flat, unsegmented network, that connection can turn a phishing email into a multi-day, six-figure line stoppage.
• The OT/IT boundary is a hard constraint, not a preference. The Purdue model encodes the rule: no direct path from the internet to a controller, and no controller depending on a cloud answer to keep running. AI's value lives at this boundary, which is exactly where the risk concentrates.
• You do not need plant-wide monitoring to deploy safely; you need to close enough of the gap around the AI's specific data path. The four moves, in order: inventory the path, segment it, make it outbound-only, and monitor it.
• Segmentation is the highest-leverage move because it converts a plant-wide compromise into a closet-sized one. A data diode or DMZ broker makes outbound-only a property of physics, not a setting a contractor can fumble.
• AI plays three security roles at once: it is a target whose inputs can be corrupted to wreck yield, an attack surface that adds doors and a vendor cloud to your supply chain, and a potential defender that can help a thin team begin closing the visibility gap.
• The customer audits you, not the vendor. The security floor doubles as the audit trail: the network diagram, asset inventory, access record, and boundary log are both your defense and your evidence. "The model flagged it" is never a sufficient answer.
• Keep AI advisory and out of direct control of anything that moves on a brownfield line. The model recommends; a named human signs. Built in order, this floor is shippable by a thin team, one lit hallway at a time.