On a Tuesday in March, a vision-inspection vendor pushed a routine software update to a plant in Ohio that grades stamped brackets at line speed. The update was meant to improve the defect model. Instead, the vendor's remote-access tool, the same tunnel they used to deploy the update, sat open on a flat network with no segmentation, and forty minutes later a piece of commodity ransomware that had been dwelling on the vendor's own laptop walked straight through that tunnel into the plant. It did not touch the vision camera. It did not need to. It found the historian, the server that records every PLC tag (PLC means Programmable Logic Controller, the industrial computer that actually runs the machine), and it encrypted six years of process data. The line ran for another two shifts before quality realized the historian feed was dead and they had no way to trace a developing defect back to a machine setting. The plant manager spent the next month explaining to an automotive customer why the traceability records for 90,000 shipped parts were gone. The vendor's contract said, in the section nobody had read, that the customer was responsible for network security. That single Tuesday is what this lesson is about: the security obligations that do not transfer to the vendor when you bolt an AI tool onto a plant you cannot fully see.

The Boundary You Are Actually Defending

Before you evaluate a single vendor, you have to be honest about the terrain you are defending. OT means Operational Technology, the networks, controllers, sensors, and software that run the physical process: the PLCs, the SCADA system (Supervisory Control and Data Acquisition, the layer that lets an operator watch and command the line from a screen), the historian, the drives, and the safety systems. IT means Information Technology, the email, the file servers, the ERP, the laptops, the things that move information rather than steel. The OT/IT boundary is the line between them, and for most of manufacturing history that line was simple because it was physical: the plant floor was an island, air-gapped, talking to nothing.

That island is gone, and the data proves it. Dragos, the firm that does nothing but study industrial threats, reports that 78% of OT networks lack centralized monitoring. Read that number the way a defender has to read it: in roughly four out of five plants, nobody can see, from one screen, what is talking to what on the floor. You cannot defend a network you cannot observe, and you certainly cannot safely add an AI tool that needs to read your PLC tags, your camera feeds, and your historian to a network where you have no idea what normal traffic even looks like. The vision vendor in the opening story did not break into a well-monitored plant. They walked into a blind one.

The reason this matters more for AI than for ordinary software is that an AI tool, by its nature, is hungry for data and chatty about it. A defect-detection model wants to read camera frames and write dispositions. A predictive-maintenance model (PdM, the practice of using sensor data to forecast a failure before it stops the line) wants to read vibration, temperature, and current from dozens of historian tags and often wants to phone those readings home to a cloud for inference. Every one of those data flows is a path across the OT/IT boundary, and every path is a potential route in. The AI vendor is selling you a model. What they are actually installing is a set of new doors in a wall you could not previously see all of.

You cannot bolt AI onto a plant you cannot see. Visibility is the first security control, and it is the one that does not come in the vendor's box.

The Obligations That Never Transfer

The single most expensive misunderstanding in floor-AI procurement is the belief that buying a vendor's product also buys their accountability. It does not. The same cardinal rule that governs quality decisions governs security: the customer audits you, not the vendor, and when the automotive OEM or the aerospace prime asks who is responsible for the integrity of the data behind a quality record, the answer on the contract and the answer the auditor accepts is the plant. The vendor is a supplier. You are the manufacturer of record.

Walk through what stays with you no matter what the sales engineer promises. Network segmentation stays with you. Putting the AI tool in a zone that cannot reach the safety PLC, the rest of the line, or the corporate network is your design and your responsibility. The vendor will configure their box; they will not redesign your network, and if they offer to, that is a red flag, not a convenience. Patch governance stays with you. When the vendor wants to push an update, the decision about when and whether that update touches a running line is a production decision, which is yours. A patch that drops at the start of a shift and reboots an inference server can stop the line as surely as a broken bearing. Remote-access control stays with you. The vendor's tunnel for support is the highest-risk door in the whole arrangement, and you own the lock: who can open it, when, for how long, and with what monitoring.

Here is the worked example that makes the cost concrete. The Ohio plant's lost historian forced a customer containment on 90,000 parts. At a fully loaded sort-and-verify cost of roughly 4 dollars per part for an outside containment, that is 360,000 dollars in pure containment labor, before a single bad part is found, before the premium-freight charges to expedite replacement traceability, and before the customer's score on your supplier rating drops and threatens the next contract. The vendor's liability cap in that contract was 50,000 dollars, the annual license fee. The math of who actually pays for a security failure is brutally one-sided, and the contract was written by the side that does not pay.

The Shared-Responsibility Fiction

Cloud and AI vendors love the phrase "shared responsibility model." It is a useful concept and a dangerous comfort. The honest version of shared responsibility is a written matrix, line by line, that says exactly who owns each control: who segments, who patches, who manages identities, who monitors, who responds when something is wrong at 2 a.m. on the night shift. The dishonest version is a sentence in a marketing deck. If a vendor cannot hand you a control-ownership matrix that maps every security obligation to a named party, then "shared responsibility" means, in practice, that everything difficult is yours and everything they want to keep is theirs. Make them write it down. The act of writing it down is itself a due-diligence test, because the vendors who have thought hard about OT security can produce the matrix in an afternoon and the ones who have not will stall.

The Due-Diligence Questions That Break the Demo

A vendor demo is engineered to show the model catching defects on a clean dataset under perfect lighting. Your job in due diligence is to ask the questions that the demo is designed to avoid, the questions about what happens on a real, brownfield, blind network on a hot afternoon. Brownfield, recall, means the plant you actually have: a 1990s PLC, a historian nobody has queried in years, mixed equipment from four decades. Greenfield plants, the clean-sheet builds, deploy AI 40 to 60% faster precisely because they do not have to answer these questions retroactively. You do.

Ask these, and weight the silence as heavily as the answer.

How does your tool connect to my OT network, and can it run without any inbound connection from the internet? The best answer is that the tool can run fully on-premises with outbound-only or no external connection. The answer that should worry you is that the tool "needs" an open inbound port or a permanent vendor VPN to function. An AI tool that cannot operate without a standing hole in your firewall is selling you its convenience at the price of your perimeter.

What data leaves the plant, where does it go, and can I turn that off? A predictive-maintenance vendor doing inference in their cloud is sending your historian data, which is a detailed map of how your process actually runs, to their servers. That may be acceptable, but it is your decision to make knowingly, not theirs to make by default. Ask whether on-premises inference is available, what the data retention is, and whether your process data is used to train models that also serve your competitors.

Walk me through your remote-support access. Is it always-on or is it broker-mediated and time-boxed? The Ohio failure was an always-on tunnel. The defensible pattern is access that you grant per-session, that expires automatically, that is logged where you can see it, and that lands the vendor in a jump host inside a segmented zone, never directly on the line. If the vendor's support model assumes they can reach in whenever they like, you have found your biggest risk before you signed.

Show me your last third-party security assessment and your SBOM. An SBOM is a Software Bill of Materials, the ingredient list of every open-source and third-party component inside the tool. A vendor who cannot tell you what is inside their software cannot tell you whether the next Log4j-style vulnerability lives in your plant. A vendor who hands you a current penetration-test summary and an SBOM without flinching is a different class of supplier than one who treats the question as an insult.

If your model is wrong, what can it actually do? Can it stop my line, change a setpoint, or fail a good part? This is the question that separates an advisory AI from a control AI. Keep the AI advisory: out of direct control of anything that moves until it is properly governed. A vision tool that lights a screen for the operator is a different risk than one wired to a reject-air-blast that can jam a line, and a PdM tool that drafts a work order is a different risk than one that can command a drive to slow down. Know exactly what the tool is permitted to touch, and design so that an AI mistake is a bad suggestion, not a stopped or damaged line.

Reading the Non-Answer

Due diligence is as much about how a vendor answers as what they answer. A mature OT-AI vendor has lived through these questions before and has crisp, specific, documented answers. An immature one, often a brilliant data-science startup that has never deployed inside a real plant, will answer security questions with reassurance ("we take security very seriously") instead of artifacts. Reassurance is not a control. Ask for the document, the matrix, the architecture diagram showing exactly where their box sits relative to your safety PLC. The vendor who has it is selling you a product that has survived a plant. The vendor who promises to "get that to you" is asking you to be their first real OT deployment, and a running line is the wrong place to be a vendor's learning experience.

Segmentation and the Purdue Discipline

The single most powerful thing you control, and the thing no vendor can do for you, is where their tool lives on your network. The classic mental model for this is the Purdue model, a layered view of a plant network that runs from Level 0 (the physical sensors and actuators) up through Level 1 (the PLCs), Level 2 (SCADA and local control), Level 3 (the plant operations and the historian), to Levels 4 and 5 (the corporate IT and the internet). You do not have to implement Purdue to the letter to use its core discipline: the lower the level, the closer to something that can hurt a person or wreck a machine, and the fewer doors there should be.

An AI vision tool reads from cameras and should write its dispositions up toward Level 3, into a quality database, not down into the control layer. A predictive-maintenance tool reads historian tags at Level 3 and should never need a path to Level 1 to command a drive. When you place the vendor's box, place it in a segmented zone, often called a DMZ (a demilitarized zone, a buffered network that sits between two trust levels and lets data cross under controlled conditions) between your OT and IT worlds, with a firewall that allows only the specific flows the tool genuinely needs and denies everything else by default. This is the control that would have stopped the Ohio ransomware cold. The malware came in through a Level 4 vendor tunnel; a properly segmented network would have trapped it in the IT zone, unable to reach the Level 3 historian at all.

Quantify the leverage. Network segmentation is among the cheapest controls in security, often a matter of a managed switch, a firewall rule set, and a few days of an integrator's time, call it 20,000 to 40,000 dollars for a meaningful segment on a single line. Set that against the 360,000-dollar containment from one blind-network incident, and segmentation is not a cost center; it is the highest-return insurance on the floor. The reason most plants skip it is not money. It is that 78% of them cannot see their OT network well enough to know what flows to allow, which is why visibility and segmentation are the same project wearing two hats.

Remote Access, the Vendor's Favorite Door

If you fix only one thing after this lesson, fix remote access, because it is the door that the highest number of real OT incidents have walked through, and it is the one vendors most want to leave propped open for their own convenience. Every AI vendor wants a way to reach into your plant to support their tool, push updates, and debug. That need is legitimate. The standing, always-on, unmonitored tunnel that most of them default to is not.

The defensible model has four properties, and you should require all four in the contract, not just the deployment. Brokered: the vendor does not connect directly to their box on your floor; they connect to a jump host or access broker that you control, sitting in the segmented zone, and from there reach only what they are allowed to reach. Time-boxed: access is granted per support session and expires automatically, so there is no permanent door, only a door you open when you choose and that closes itself. Authenticated and least-privilege: a named human at the vendor authenticates with multi-factor authentication, and that account can touch only the AI tool, never the rest of the line, the historian, or the corporate network. Logged where you can see it: every session is recorded in a place your team monitors, not only in the vendor's own logs, because the whole point is that you can see what they did.

Picture the Ohio incident replayed under this model. The vendor wants to push the update. They request a session. Your night-shift lead grants a two-hour window. The vendor authenticates with MFA into the jump host. Their account can reach the vision server and nothing else. The ransomware on their laptop tries to follow, but the jump host is in a segmented zone with no path to the historian, the session is monitored, and the anomalous traffic trips an alert. The whole event is a contained scare instead of a 360,000-dollar containment and a month of explaining to a customer. The difference between those two Tuesdays is not the vendor's product. It is the four properties of the door, which only you can install.

Building It Into the Contract and the Program

Due diligence that lives only in a conversation evaporates the day the deal closes. The obligations have to land in the contract and then in a repeatable program, because you will buy more than one AI tool and you do not want to relearn this lesson on each. The contract is where "shared responsibility" stops being a slogan and becomes enforceable.

Put these terms in writing. The security control matrix as an exhibit: the line-by-line who-owns-what, attached and signed, so there is no later argument about whether patching or monitoring was theirs or yours. A defined patch and update process: updates are proposed, tested in a non-production environment or a maintenance window, and never auto-pushed to a running line without your authorization. Breach notification with a real clock: if the vendor is compromised, you learn within a defined number of hours, not when you discover your own historian is encrypted. Right to audit and to receive the SBOM and assessment on a cadence: security is not a one-time gate, it is an annual obligation, because the threat landscape and the vendor's own software both change. An exit and data-portability clause: when the relationship ends, your process data comes home in a usable form and the vendor's access is provably revoked.

Then make it a program rather than a heroic one-off. Stand up a short, standard OT-AI vendor due-diligence checklist, the questions from the section above plus your contract terms, and run every floor-AI purchase through it, the same way quality runs every new supplier through a PPAP (Production Part Approval Process, the standardized package that proves a supplier can make a part to spec). Bring the right people to the table: OT and controls engineering, IT security, quality, and operations, because an AI tool that crosses the OT/IT boundary is exactly the kind of decision none of those functions can make alone. A plant that has this checklist is the plant that can say yes to AI quickly and safely, while its competitors are still arguing about whether the demo was real. That speed, grounded in discipline rather than optimism, is the whole point. You are not trying to keep AI off the floor. You are trying to let a thinner, greener crew deploy it onto a plant they can finally see, defend, and audit.

Key Takeaways

• The security obligations that matter most never transfer to the vendor: network segmentation, patch governance, and remote-access control stay with the plant, because the customer audits you, not the vendor, and you are the manufacturer of record.
• You cannot defend or safely add AI to a network you cannot see, and 78% of OT networks lack centralized monitoring. Visibility and segmentation are the same foundational project, and they are prerequisites to any floor-AI deployment, not afterthoughts.
• "Shared responsibility" is only real when it is a signed, line-by-line control-ownership matrix. A vendor who cannot produce that matrix is telling you, in effect, that everything hard is yours.
• The due-diligence questions that break the demo are about the real plant: how the tool connects without an inbound hole, what data leaves and whether you can stop it, how remote support is brokered and time-boxed, whether the vendor can show an SBOM and a recent assessment, and exactly what the model is permitted to touch if it is wrong.
• Keep the AI advisory and out of direct control of anything that moves until it is properly governed, so that a model mistake is a bad suggestion rather than a stopped or damaged line.
• Remote access is the vendor's favorite door and the route most real incidents take. Require brokered, time-boxed, least-privilege, monitored access in the contract, not just the deployment, and the same incident becomes a contained scare instead of a six-figure containment.
• Segmentation at 20,000 to 40,000 dollars per line is the highest-return insurance on the floor against a single blind-network incident that can cost 360,000 dollars in containment alone, well beyond a typical vendor liability cap.
• Make due diligence a repeatable program with a standard checklist, contract terms (control matrix, patch process, breach-notification clock, audit and SBOM cadence, exit clause), and the right people at the table: OT, IT security, quality, and operations together.