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

It is the middle of the night shift. A servo drive on a packaging line has faulted, the error code is cryptic, and the OEM manual is no help. The technician opens a browser on the engineering workstation, goes to a public AI chatbot, and pastes in the ladder logic around the fault along with the recipe parameters for the product on the line. The chatbot suggests a fix. The line restarts. Nobody outside that shift ever knows.

This is shadow AI: people using AI tools the organization has not approved, for work the organization cares about. On the plant floor it rarely looks like a security incident. It looks like a resourceful employee getting the line running. That is exactly why it is hard to see, and why banning it rarely works.

This article covers why plant data is a special case, how to map where AI is already in use, the governance steps that cost little, and how to offer approved tools that people will choose over the public ones.

Why plant data is different

Office data loss prevention is built to spot things like customer records, payment data, and documents marked confidential. Plant know-how looks different:

Much of this is the kind of technical and engineering information that trade secret law protects. Under the U.S. definition, information qualifies only if its owner has taken reasonable measures to keep it secret ^[1]. A clear rule about what may be pasted into public AI tools, and evidence that people were trained on it, is part of what reasonable measures look like.

There is also a model-side risk. The OWASP Top 10 for LLM Applications 2025 lists sensitive information disclosure as LLM02 ^[2]. Whether a given public tool retains or trains on what users submit depends on the product and the account terms, so treat anything pasted into an unmanaged account as having left your control.

How shadow AI gets onto the plant floor

The path is usually ordinary:

• Engineering workstations with internet access. Browsers on machines that also hold PLC software and project files.
• Personal phones. Photos of nameplates, HMI screens, and error codes sent to AI apps.
• Embedded AI in everyday tools. Assistants built into office software, browsers, and code editors that users may not think of as AI services.
• Vendor and contractor laptops. Outside staff using their own tools on your equipment.

Web proxies and firewalls may classify AI services as general productivity traffic rather than as places data leaves the company, so the traffic is allowed and unremarkable.

Use the frameworks you already have

You do not need to invent an AI governance program from scratch.

In December 2025, CISA, the Australian Signals Directorate's Australian Cyber Security Centre, the FBI, the NSA, and international partners published Principles for the Secure Integration of Artificial Intelligence in Operational Technology ^[3]. Its four principles map directly to plant work: understand AI, including educating personnel on AI risks; assess AI use in OT, including managing OT data security risks; establish AI governance; and embed safety and security, including oversight and incident response ^[3].

The NIST AI Risk Management Framework, released in January 2023, is intended for voluntary use to help organizations incorporate trustworthiness considerations into the design, development, use, and evaluation of AI systems, and NIST added a Generative AI Profile in July 2024 ^[4]. For the network side, NIST SP 800-82r3 provides guidance on securing OT while addressing its unique performance, reliability, and safety requirements ^[5].

Map the shadow AI surface in your plant

Start with facts, not assumptions:

1. DNS and proxy logs. List AI service domains reached from plant and engineering networks, by site and device type. Look at engineering workstations first. 2. Interviews. Ask technicians, engineers, and planners which AI tools they use and for what. Make it clear this is about understanding needs, not punishment, or you will learn nothing. 3. Software inventory. Note AI features in tools IT has already deployed, which may be in use without anyone thinking of them as AI. 4. Vendor practices. Ask OEMs, integrators, and contractors what AI tools they use on your equipment and data.

Classify what you find by the data involved, using the table above, and by who is using it. That gives you a short list of the highest-risk uses to address first.

Build an internal AI registry

A registry is a simple, published list of AI tools with a status for each:

Give each entry an owner, the data types it may touch, and the date it was last reviewed. Publish it where technicians will actually see it, such as the shift handover board and the maintenance portal, not only on the IT intranet.

Rewrite SOPs before you buy a tool

Most of the risk reduction comes from clear rules people understand, and updating procedures costs very little:

• Add a data-handling line to troubleshooting SOPs. What may and may not be shared with AI tools, with examples: no PLC programs, recipes, setpoints, or drawings in public tools.
• Name the approved alternative in the same place, so the rule comes with a way to get the job done.
• Train by role. Technicians, controls engineers, and planners handle different data and need different examples.
• Include contractors in onboarding and contracts.
• Add AI to incident response. Say what to do if someone realizes they pasted sensitive data into a public tool, without making them afraid to report it.

Governed alternatives people will actually use

An approved tool only wins if it solves the same problem faster. For a technician at a faulted machine, that means:

• Answers grounded in your own documents: OEM manuals, past work orders, and approved procedures, so the advice fits your equipment.
• Access where the work happens: on the device the technician already carries, without extra logins.
• No more steps than the public option. Every extra click is a reason to go back to the public tool.
• Clear data boundaries: an enterprise agreement that covers retention and training, and access controls by role.

Purpose-built maintenance AI is one option. 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 and ask the people who stopped using the approved tool why. They will tell you what is wrong. Capturing the fixes technicians find in a shared knowledge hub also preserves know-how that would otherwise stay in one person's head; our maintenance memory capture framework covers how.

Five actions for this week

1. Pull DNS or proxy logs for AI domains from engineering and plant networks. 2. Hold three short interviews with a technician, a controls engineer, and a planner about the AI tools they use. 3. Publish a first registry with the tools you already know about and their status. 4. Add one data-handling line to the troubleshooting SOP for your most critical line. 5. Name an owner for AI governance on the plant side, working with the CISO.

For the broader picture of AI recommendations in maintenance, see our trust scorecard for AI maintenance recommendations.

Frequently asked questions

What is shadow AI in manufacturing?

The use of AI tools the organization has not approved, such as public chatbots or AI features in personal apps, for work involving plant data like PLC programs, recipes, or equipment photos.

Why doesn't ordinary data loss prevention catch it?

Because plant know-how looks like code, numbers, configuration exports, and images, not like the customer or financial data DLP rules are built to recognize.

Should we block public AI tools on plant networks?

Restricting them on engineering networks can be appropriate, but blocking without an approved alternative tends to push usage onto personal devices. Pair restrictions with a governed tool.

Which frameworks apply?

The December 2025 joint CISA and partner principles for AI in OT ^[3], the NIST AI Risk Management Framework ^[4], and NIST SP 800-82r3 for OT security ^[5] are good starting points.

References

[1] Legal Information Institute, "18 U.S. Code 1839, Definitions." https://www.law.cornell.edu/uscode/text/18/1839

[2] OWASP, "Top 10 for LLM Applications 2025." https://genai.owasp.org/llm-top-10/

[3] CISA, "CISA, Australia, and Partners Author Joint Guidance on Securely Integrating Artificial Intelligence in Operational Technology," December 3, 2025. https://www.cisa.gov/news-events/alerts/2025/12/03/cisa-australia-and-partners-author-joint-guidance-securely-integrating-artificial-intelligence

[4] NIST, "AI Risk Management Framework." https://www.nist.gov/itl/ai-risk-management-framework

[5] NIST, "SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security," September 2023. https://csrc.nist.gov/pubs/sp/800/82/r3/final