Behind the Curtain: The new existential threat to AI

By Gammatek ISPL , Industrial Systems & Compliance Analyst at Gammatek ISPL

Last updated: August 2026 | 11 min read

Author credibility block: Gammatek ISPL advises manufacturing, chemical, and pharmaceutical plants on industrial safety, compliance, and network security architecture at Gammatek ISPL, drawing on direct work auditing OT/IT environments across + industrial facilities. This article is independent analysis, not sponsored by any vendor named below.

"AI has entered plant floors through sensors, predictive maintenance tools, and vision systems — often faster than security policy has kept up.

If your plant has added a predictive maintenance sensor, an AI-powered quality-control camera, or an automated scheduling tool in the last two years, you've already introduced a new class of risk into your industrial control system — and there's a good chance nobody has formally reviewed it from a security standpoint. That's the gap this article is about: not a hypothetical future threat, but a real, present blind spot forming quietly on plant floors right now, because AI tools are being adopted operationally faster than security and compliance teams are being looped in.

This matters because industrial control systems (ICS) were never designed with today's kind of connected, data-hungry AI components in mind. A PLC from a decade ago and an AI vision system installed last quarter now sit on overlapping infrastructure, often without anyone mapping out what that means for your attack surface. If you run — or advise on — a manufacturing, chemical, or pharmaceutical facility, this is worth understanding before it becomes an incident report instead of a blog post.

How AI Quietly Entered the Plant Floor

Unlike a firewall or an ERP system, AI tools rarely arrive through a single, formal IT procurement process. They show up in smaller, distributed ways:

• A maintenance team installs a vendor's AI-based vibration sensor to predict equipment failure.

• A quality control line adds a machine-vision camera with a cloud-connected AI model to catch defects.

• A plant manager adopts an AI scheduling or inventory tool that pulls live data from the production line.

Each of these, on its own, looks like a productivity upgrade — and often is. The issue is that each one also opens a new data channel, frequently to a third-party cloud service, running on infrastructure that was scoped for operational efficiency, not security review. In Gammatek's own compliance audits across manufacturing and pharma clients, this is one of the most common gaps we now find: AI-enabled devices present on the network with no corresponding entry in the facility's security or compliance documentation.

That's the core of the hidden risk — not that AI itself is dangerous, but that it's arriving through operational purchasing decisions rather than security-reviewed IT procurement, which means it bypasses the usual checkpoints.

Why This Is Different From Traditional OT Security Risk

Industrial security conversations over the last decade have mostly focused on segmenting OT (operational technology) from IT — keeping legacy PLCs and SCADA systems isolated from the internet-facing side of the business. That's still essential. But AI-enabled devices complicate this model in three specific ways:

1. They often require live, continuous data flow. A predictive maintenance sensor isn't useful sitting in an isolated network segment — its value comes from continuously sending data to a cloud model and receiving analysis back. That live connection is precisely the kind of pathway traditional OT segmentation was built to eliminate.

2. The vendor's cloud infrastructure becomes part of your attack surface. When an AI tool processes plant data off-site, your security posture now partially depends on a third party's practices — patching cadence, data handling, breach history — that your own team doesn't control and may not have visibility into.

3. AI models can be manipulated in ways traditional systems can't. A malicious actor targeting an AI-based quality control system doesn't necessarily need to breach the network directly — subtly poisoned training data or adversarial inputs can degrade the model's accuracy without tripping conventional intrusion detection at all. This is a genuinely new category of risk that most existing ICS security frameworks weren't built to address.

A Real Example: What This Looks Like in Practice

In one facility Gammatek worked with — a mid-size chemical processing plant — the security team discovered during a routine compliance audit that a predictive maintenance vendor's sensors, installed eight months earlier by the operations team, had an open outbound connection to the vendor's cloud platform that had never been reviewed against the plant's network segmentation policy. Nothing malicious had happened. But the sensors sat on the same VLAN as several legacy PLCs, meaning a compromise of the vendor's cloud service could theoretically have provided a pathway toward equipment that had no business being reachable from the internet at all.

The fix wasn't to remove the AI tool — the predictive maintenance value was real and worth keeping. It was to retroactively map every AI-connected device in the facility, move them onto their own reviewed and monitored network segment, and add them formally to the plant's compliance documentation so future audits and security reviews would actually account for them. That gap — AI devices existing operationally but not existing on paper — is the pattern we now check for specifically in every audit.

Quick Comparison: Traditional ICS Risk vs. AI-Introduced Risk

	Traditional ICS/OT Risk	AI-Introduced Risk
Entry point	Formal IT/OT procurement	Operational/departmental purchasing
Network behavior	Often isolated, minimal external connection	Requires continuous cloud connectivity
Attack surface	Defined by internal network topology	Extends to third-party AI vendor infrastructure
Detection method	Traditional intrusion detection, network monitoring	Requires model-behavior monitoring, not just network monitoring
Typical blind spot	Unpatched legacy equipment	Undocumented shadow AI deployments

What Manufacturers Should Actually Do About This

This isn't a call to avoid AI tools — the operational value (fewer breakdowns, better quality control, real efficiency gains) is real and, in most cases, worth pursuing. It's a call to bring these tools into your existing security and compliance process instead of letting them arrive quietly through operational purchasing.

Practical steps worth taking in the next quarter:

• Inventory every AI-enabled device and tool currently connected to your network — most facilities are surprised by how many exist once they actually look.

• Map data flow for each one — where does the data go, who processes it, and does that vendor's security posture meet your own standards?

• Bring AI tool purchases into the same review process as any other network-connected device, regardless of which department is buying it.

• Update your compliance documentation to reflect AI-enabled devices explicitly — audits (internal or regulatory) increasingly expect this, and undocumented devices are a common finding.

• Segment AI-connected devices onto their own reviewed network zone, separate from both core OT and general IT, so a vendor-side incident doesn't have a direct path to production equipment.

Where This Is Heading

Regulatory frameworks are starting to catch up to this gap. Expect compliance standards for manufacturing, pharma, and chemical facilities to increasingly require explicit documentation of AI-connected devices and their data flows — not as a hypothetical, but as a natural extension of existing OT/IT segmentation requirements. Plants that build this inventory and review process now, before it's mandated, will have a much easier time when it is.

The broader pattern worth remembering: every wave of plant-floor technology — from early SCADA systems to IoT sensors to now AI tools — has followed the same arc. Operational teams adopt it for the productivity gain first; security and compliance catch up later, usually after an incident makes the gap obvious. The plants that break that pattern are the ones that build AI tool review into their existing security and compliance process from the start, rather than waiting for an audit — or worse, an incident — to surface it.