Shadow AI on the Manufacturing Floor: The Governance Gap Your CISO Doesn't See

It is 2:14am on a Tuesday. Your second-shift maintenance tech, call him Danny, is staring at a faulted servo drive on Packaging Line 3. The Allen-Bradley CompactLogix is throwing a cryptic error, and the OEM manual is 400 pages of nothing useful. Danny does what any resourceful technician would do in 2024: he opens Chrome on the engineering workstation, navigates to ChatGPT, and pastes 47 rungs of proprietary ladder logic along with the batch recipe parameters for your highest-margin product. He gets a decent troubleshooting answer in 90 seconds. The line is back up by 2:31am.

Nobody in your organization knows this happened. Your firewall logged it as standard HTTPS traffic to an OpenAI endpoint, indistinguishable from someone checking Reddit. Your DLP system didn't trigger because it was scanning for Social Security numbers and credit card patterns, not for Structured Text programs or PID tuning constants. Your CISO's monthly report shows zero data exfiltration incidents.

Danny isn't malicious. He's resourceful. And he's not alone. According to a 2024 Gartner survey, 67% of CISOs report zero visibility into generative AI usage within operational technology environments. Manufacturing is the most exposed vertical for shadow AI because the data that matters most (process logic, setpoints, recipes) doesn't look like "sensitive data" to any tool in the traditional security stack.

The 2am Troubleshooting Session That Cost $4.7M in IP

Let me make this concrete. A mid-size food manufacturer I worked with discovered during a routine IT audit that over a six-month period, maintenance technicians had pasted Allen-Bradley PLC code, proprietary batch parameters, alarm threshold tables, and CNC toolpath data into public LLM interfaces more than 340 times. The engineering team later valued the exposed intellectual property at $4.7M, factoring in the R&D investment behind their proprietary process tuning and the competitive advantage it represented.

The company only found this because an IT intern was running Splunk queries for a different project and noticed repeated DNS lookups to api.openai.com from a subnet that should have been entirely OT traffic. Without that accident, the exposure would have continued indefinitely.

This is not a hypothetical attack vector. Every major LLM provider's terms of service state they may use input data for model training unless you are on an enterprise plan with explicit data retention opt-outs. When Danny pastes your proprietary ladder logic into the free tier of ChatGPT, that code potentially becomes part of the training corpus. Your competitors' engineers could, in theory, receive fragments of your process knowledge in their own ChatGPT responses months later.

The financial exposure extends beyond IP valuation. If your company holds ITAR-controlled technical data, or if your process parameters fall under trade secret protections, unauthorized disclosure to a third-party AI service could trigger regulatory consequences. One defense contractor discovered that maintenance staff had inadvertently exported controlled technical data through Copilot prompts, resulting in a six-figure compliance remediation.

Why Your DLP Stack Is Blind to Process Knowledge

Traditional Data Loss Prevention tools were designed for a different era and a different kind of sensitive data. They excel at pattern matching: 16-digit numbers that look like credit cards, 9-digit numbers formatted like SSNs, and strings matching PHI patterns from HIPAA. They are functionally blind to the data types that represent real manufacturing IP.

Consider what operators are actually pasting into LLMs:

• PLC ladder logic and Structured Text from RSLogix 5000 or Siemens TIA Portal
• Process setpoints and recipe parameters exported from FactoryTalk Batch or Wonderware InBatch
• Alarm threshold tables that reveal exactly how you've tuned your process for quality and yield
• Proprietary PID tuning constants representing months of process engineering optimization
• CNC G-code containing custom toolpaths for proprietary part geometries

None of these trigger DLP rules. They are plain text. They contain no regulated data patterns. To a DLP engine, a 200-line Structured Text program looks identical to a Reddit comment.

The web proxy layer compounds the problem. Most enterprise proxy solutions (Zscaler, Netskope, Palo Alto Prisma) categorize ChatGPT, Claude, and Microsoft Copilot under "Productivity" or "AI/ML" traffic categories. They are not flagged as "Data Exfiltration" or "Cloud Storage" risks unless you manually reclassify them. In my experience, fewer than 15% of manufacturing organizations have bothered to recategorize these domains.

Compare this to financial services. When Bloomberg rolled out its Terminal AI features, banks immediately implemented input monitoring, data classification layers, and usage logging. They treated every AI interface as a potential data egress point. Manufacturing has done almost none of this. OT engineering workstations sit on network segments with minimal content filtering, often running outdated browsers, and frequently shared between multiple technicians who all know the same login credentials.

Mapping the Shadow AI Attack Surface in Your Plant

Before you can govern shadow AI, you need to see it. Here is a concrete process that takes less than a week if you have access to your network logs.

Step 1: DNS log analysis. Pull 30 days of DNS query logs from your OT network segments. Filter for these domains: `api.openai.com`, `chat.openai.com`, `claude.ai`, `api.anthropic.com`, `gemini.google.com`, `copilot.microsoft.com`, and `bard.google.com`. If you are running Splunk, the query is straightforward. In Palo Alto, check the URL filtering logs. Even a basic Pi-hole on the OT network will give you this data.

Step 2: No-blame interviews. Schedule 20-minute conversations with second and third shift supervisors. Frame it as "We want to understand what tools people use to troubleshoot, so we can provide better ones." Do not frame it as an investigation. Technicians will tell you exactly what they are doing if they do not feel threatened. In every plant I have visited, the answer has been some variant of: "Yeah, most of us use ChatGPT when the manual doesn't help."

Step 3: Workstation audit. Check browser histories on shared engineering workstations, particularly those running RSLogix, TIA Portal, FactoryTalk View, or Ignition. Focus on machines in control rooms and maintenance offices. Look for bookmarked AI tools and saved prompts.

Step 4: Build a heat map. Organize your findings by shift, department, and role. In most plants, you will see usage concentrated on second shift (fewer supervisors, more pressure to fix things fast), in maintenance and process engineering departments, and among mid-career technicians who are comfortable with technology but not senior enough to have access to OEM support lines.

Building an Internal AI Registry in Two Weeks

An AI registry is not a software purchase. It is a spreadsheet that becomes a living document. You can build one in two weeks with zero budget.

Week 1: Discovery and Classification

Inventory every AI tool in use across the organization, sanctioned and unsanctioned. Your DNS analysis and interviews from the mapping exercise give you 80% of this list. Add any tools IT has provisioned (GitHub Copilot for software teams, Grammarly for marketing, etc.).

For each tool, classify the sensitivity of data that users are inputting. Use a three-tier system:

• Green: Public data only. Product spec sheets, publicly available maintenance procedures, general technical questions with no proprietary context.
• Yellow: Anonymized process data. Generic troubleshooting questions that strip out specific setpoints, part numbers, and product names.
• Red: Never input. PLC code, recipe parameters, alarm configurations, PID constants, CNC programs, customer-specific production data, anything ITAR-controlled.

Week 2: Publication and Ownership

Publish the registry in your existing document management system. Do not create a new SharePoint site or wiki that nobody will visit. Put it where your SOPs already live, whether that is MasterControl, Veeva, Documentum, or a shared drive your teams actually open.

Assign an owner to each registry entry. This person is responsible for reviewing the tool quarterly and updating its risk classification. Connect new AI tool requests to your existing Management of Change (MOC) process. If adding a new chemical to the plant requires an MOC review, adding a new AI tool that ingests process data should require the same.

Rewriting SOPs Before You Buy a Single Tool

The fastest, cheapest governance control you can deploy is updating your existing Standard Operating Procedures. This costs nothing but a few hours of writing time, and it creates a documented expectation that protects the company legally.

Add a section titled "Digital Tool Data Handling" to every maintenance and troubleshooting SOP. Be explicit. Do not write "employees should exercise caution when using AI tools." Instead, write: "Do not paste PLC ladder logic, Structured Text, function block diagrams, process setpoints, or recipe parameters into any external website or AI tool, including ChatGPT, Claude, Copilot, or Gemini."

Operators respond to specificity. "Don't share sensitive data" is meaningless. "Don't paste the contents of your RSLogix project file into ChatGPT" is actionable.

Create a one-page laminated reference card for control rooms. Title it "Before You Paste" and structure it as a simple decision tree: Is the data publicly available? If yes, proceed. Does it contain any machine-specific code, setpoints, or parameters? If yes, stop. Use the internal tool or call the OEM.

Finally, update your annual refresher training. Do not create a standalone "AI security" training module that people will click through mindlessly. Instead, add a 10-minute segment to your existing safety refresher. Put AI data handling right after lockout/tagout and confined space procedures. The proximity signals importance.

Governed Alternatives That Operators Will Actually Use

Here is the hard truth about governed AI alternatives: if the approved tool takes more clicks, more time, or more friction than pasting into ChatGPT, operators will ignore it. I have seen this pattern repeatedly. A company deploys an internal LLM with great fanfare, usage peaks at 40% in week two, and drops to single digits by month three because the interface is clunky and the responses are worse.

The governed alternative must solve the same problem in equal or fewer steps. Period.

Option 1: Self-hosted LLM with RAG. Deploy Llama 3 or Mistral on an internal GPU server behind the firewall. Build a Retrieval Augmented Generation pipeline over your own maintenance knowledge base: OEM manuals, historical work orders from your CMMS, tribal knowledge documents, and past troubleshooting logs. Tools like Ollama make local deployment accessible even without a dedicated ML team. The advantage: zero data leaves your network. The disadvantage: response quality depends entirely on your knowledge base quality, which in most plants is terrible.

Option 2: Enterprise LLM with guardrails. Azure OpenAI or ChatGPT Enterprise with data retention disabled, DLP input scanning enabled, and pre-approved prompt templates for common troubleshooting scenarios. This gives operators the same GPT-4 quality they are used to, with contractual guarantees that input data is not used for training. Pre-built prompt templates ("Describe the servo fault symptoms without pasting any code") reduce the temptation to dump raw PLC logic.

Option 3: Purpose-built maintenance AI. Tools like Monitory embed predictive intelligence directly into the maintenance workflow. Instead of asking a general-purpose LLM to interpret PLC faults, operators get AI-driven diagnostics that are already connected to their sensor data, CMMS work orders, and equipment history. The AI never sees raw process code because it is working from structured telemetry, not copy-pasted ladder logic.

Measure adoption weekly for the first 90 days. If usage drops below 60%, the problem is UX, not policy. Survey the operators who stopped using it. They will tell you exactly what is wrong.

The Monday Morning Playbook: 5 Actions This Week

Stop reading and start here. These five actions require no budget approval, no new software, and no organizational restructuring. You can complete all five before Friday.

1. Run the DNS query. Pull 30 days of DNS logs from your OT network segments. Filter for `openai.com`, `anthropic.com`, `claude.ai`, and `gemini.google.com`. Count the hits. Note the source IPs. Map them to specific workstations and departments. This takes an hour if you have Splunk access.

2. Talk to three second-shift techs. Schedule 20-minute conversations. Ask: "When you are troubleshooting at 2am and the manual is not helping, what do you do?" Listen without judgment. Document what you hear. These conversations will tell you more than any security audit.

3. Draft the SOP addendum. Write a one-page "Digital Tool Data Handling" section for your five most frequently used maintenance SOPs. Be specific about what data types cannot be shared externally. Get your controls engineering lead to review it. Publish it by Thursday.

4. Add AI to the maintenance review agenda. Your next monthly maintenance review meeting should include a 15-minute standing agenda item: "AI and Digital Tool Usage." Review any new tools discovered, discuss the registry, and address operator feedback on governed alternatives.

5. Brief your CISO. Walk into that meeting with the DNS query results, the interview findings, and a one-page proposal for a 30-day AI governance sprint. CISOs respond to data, not hypotheticals. Showing them 340 DNS hits to OpenAI from the OT network will get their attention in ways that a policy memo never would.

Danny is going to troubleshoot that servo fault at 2am regardless of what policy you write. Your job is not to stop him from using AI. Your job is to make sure the AI he uses does not send your most valuable process knowledge to a server you do not control. The gap between those two outcomes is about two weeks of focused work and zero dollars in new tooling.

Start with the DNS query. You will not like what you find, but you will finally see the problem clearly enough to fix it.