OT Security Meets AI: Blind Spots in the Plant Floor

Author: Roger Hill

AI cannot protect what it cannot see, and in plants, the most important signals are often invisible

The flashlight problem

AI in OT security is being marketed as a breakthrough in visibility. Dashboards fill with asset inventories, anomaly scores, and traffic maps that suggest comprehensive coverage. For executives responsible for resilience, it looks like a long-awaited solution.

But AI is not a floodlight that reveals every corner of a plant. It is a flashlight. It illuminates what you point it at and leaves the rest in shadow. That distinction matters. The risk is not that coverage is partial—executives can manage that. The risk is when partial coverage is mistaken for total coverage, and leaders make decisions on the belief that blind spots no longer exist.

Where the light doesn’t reach

The blind spots in OT environments are structural. They are not a failure of AI; they are a reality of how industrial systems were designed.

Consider the control cabinet. Many still use unmanaged switches that do not support port mirroring. The conversations between a Programmable Logic Controller (PLC), a Human–Machine Interface (HMI), and a drive never leave the box. If sensors are positioned at the network core, they will never capture that traffic. The AI model built on those feeds has nothing to analyze.

Or take the engineering workstation. A controls engineer connects directly to a PLC for a quick update. That session is point-to-point. It bypasses taps, spans, and anomaly detection entirely. If malware moves across that session or logic is changed, there will be no record.

Logs pose a similar problem. Systems such as SCADA servers, historians, and MES platforms generate records that can help detect misuse. Yet many plants do not centralize or retain these logs consistently. AI log analysis can only work with what is collected. When the data is absent, the analysis is silent.

Even SIEM, which in IT aggregates security events across the enterprise, faces limits in OT. Embedded devices like PLCs, DCS controllers, and motion systems were never designed to generate SysLog or similar event streams. They simply do not speak. The only practical alternative is to monitor the PC-based systems that interact with them—engineering workstations, SCADA servers, operator HMIs, historians. Those endpoints act as proxies. It is valuable, but it is indirect and incomplete.

How the message changes on its way up

At the engineering level, these blind spots are well understood. Network architects know which cabinets cannot be mirrored. Controls teams know which laptops connect directly. Security specialists know which logs exist and which don’t.

When security teams evaluate anomaly detection platforms, they work within those constraints. They collect what they can, deploy endpoint tools where possible, and feed available logs into SIEM. The dashboards look promising. Asset inventories expand. Baselines stabilize.

But as the information moves upward, the nuance erodes. P&L owners—the people approving spend—hear about improved visibility and AI-driven insights. The technical caveats often do not make it into the briefing. By the time results are presented to a board, what survives is the headline: “We’ve deployed AI to increase visibility and resilience.”

This is not intentional distortion. It is compression. Complex technical realities are flattened into business language. The blind spots are still there, but they are no longer part of the conversation.

False assurance as the real risk

Every plant has blind spots. That is expected. The real concern is when those blind spots disappear from the picture leaders use to make decisions.

Partial visibility can be managed. Executives can set compensating controls, govern accordingly, and disclose residual risk. False visibility is more dangerous. It creates misplaced confidence. Budgets shift elsewhere. Controls are relaxed. Risk statements to regulators and insurers overstate resilience. Then, when an incident occurs in the unseen corners, the gap between perception and reality becomes painfully clear.

This is the governance failure to guard against. Not that AI misses things—that is a given—but that its limitations are not consistently surfaced in the way assurance is communicated.

A scenario to test the claim

Picture a manufacturer that deploys AI-enabled anomaly detection across several plants. Dashboards fill with new asset inventories, baseline maps, and anomaly scores. The business case cites expanded visibility, and the rollout is approved for more sites.

Months later, a PLC fails with a fault condition following a rushed programming change. The engineer connected directly from a laptop, bypassing all monitoring systems. No logs were captured, and the AI system raised no alert.

On the plant floor, this is no surprise. Engineers knew direct connections are invisible. Security teams may have flagged it in risk registers. But those caveats never made it into the business case that justified the spend. What reached executives was “visibility improved.” What reached the board was “resilience enhanced.” Both statements were technically accurate. Neither told the whole story.

What leaders should actually expect

AI promises improved anomaly detection. Vendors claim it will accelerate asset discovery, identify out-of-pattern flows, and summarize logs faster than people alone. But these promises cannot rewrite the fundamentals: you cannot analyze data that is never collected, and in OT environments, some data will simply never be collected.

For P&L owners, this means treating AI promises with scrutiny. Ask for evidence of what the platform actually ingests. Require visibility assurance as part of every funding proposal. If a percentage of activity remains unobserved, that percentage should be disclosed.

For boards, the role is not to debate network protocols. It is to test the credibility of assurance. When management reports improved visibility, are they also disclosing what remains unseen? Oversight is about ensuring executives are not compressing nuance into slogans.

The smart path is not to reject AI anomaly detection. It is to apply rigorous system architecture principles to minimize blind spots from the start.

Begin with a comprehensive design analysis of your OT environment. Apply systematic engineering requirements to network architecture, ensuring monitoring capabilities are built into the infrastructure rather than added as an afterthought. Configure systems with visibility as a core requirement, not just operational efficiency. Properly tune detection mechanisms based on criticality assessments of each system component.

Then create a visibility governance framework. Document what is captured and what remains outside view. Quantify coverage with metrics that matter to both engineers and executives. Where monitoring gaps remain despite architectural improvements, implement robust compensating controls: cryptographically signed logic changes, secure jump hosts for programming sessions, and formal attestation procedures. Ensure this comprehensive view is presented whenever visibility is reported up the chain.

Closing thought

AI in OT security is a flashlight, not a floodlight. It is useful. It reveals things that were hidden. But it does not change the architecture of plants, and it does not eliminate blind spots.

The responsibility of leadership is not to expect perfection from the tool but to demand honesty in how its limits are reported. Engineers know where the light doesn’t reach. Security teams can articulate it. P&L owners must insist it is disclosed. Boards must ensure the assurances they receive reflect the full picture.

The next time a dashboard makes the plant look completely visible, pause and ask: are we governing to what is actually seen, or to what the dashboard makes us believe?

Follow us on LinkedIn for more OT cybersecurity content and announcements: https://www.linkedin.com/company/hillstrong-group-security