Shadow AI on the shop floor: a practical AI policy for manufacturers

AI is already in your plant. The question is where the data went.

Nobody filed a ticket asking for AI. It just showed up.

An estimator pastes an RFQ into a chatbot to clean up a quote. A quality tech uploads a photo of a nonconformance report to get a summary. An engineer drops a drawing note into a free tool to translate it for an overseas supplier. A plant manager uses a browser extension that "helps" with email.

None of these people are trying to cause a problem. They are trying to get through the day faster. That is exactly why it matters: the most useful data to paste into an AI tool is usually the data you least want leaving the building.

That is shadow AI. Not a rogue robot. Just everyday tools nobody approved, holding data nobody tracked.

Why a ban does not work

The first instinct is to block it. Put ChatGPT on the firewall deny list, send a memo, done.

In practice:

• People switch to personal phones and home laptops, where you have zero visibility
• New AI features show up inside tools you already approved (email, office suites, CAD, ERP add-ons), so the block list is out of date by next month
• The people who were being careful stop asking, because the answer is always no

A ban moves the risk somewhere you cannot see it. A policy gives people a safe lane and makes the unsafe lane obvious.

What is actually at risk for a manufacturer

Think in terms of the data, not the tool:

• Customer drawings and specs. Often covered by NDAs, export rules, or customer contract terms
• CUI and covered defense information. If you do DoD work, DFARS 252.204-7012 already sets rules for where that data can be stored and processed. A free consumer AI tool is not on that list
• Pricing, quotes, and margins. The stuff your competitors would love to see
• Supplier and employee data. Contracts, HR issues, personal information
• Process know-how. Setups, recipes, tolerances, and the tribal knowledge that makes your shop better than the one down the road

If a tool's terms let the vendor keep or train on what you paste in, assume that data is no longer only yours.

The practical policy: five parts

You do not need a 40-page document. You need something a shift lead can read in ten minutes and actually follow.

1. Data rules in plain language

Sort your data into three buckets and say what is allowed for each:

| Bucket | Examples | AI use | | --- | --- | --- | | Public | Marketing copy, published specs, job postings | OK in approved tools | | Internal | SOPs, general emails, meeting notes | Approved business tools only, signed in with a work account | | Restricted | CUI, customer drawings, pricing, HR, export-controlled data | Not allowed unless the tool is explicitly approved for that data |

If people remember one rule, it should be this: if you would not email it to a stranger, do not paste it into an unapproved AI tool.

2. An approved tool register

Keep a short list: tool name, who owns it, what data bucket it is approved for, and whether it is tied to work accounts. Start with what people already use. You will usually find two or three tools covering most of the real demand.

Anything not on the list is not approved yet. Give people a simple way to request a tool so the register grows instead of getting bypassed.

3. Risk tiers for how AI is used

Not every use carries the same risk:

• Low: Drafting a generic email, summarizing a public article, brainstorming
• Medium: Summarizing internal documents, writing SOP drafts, analyzing non-restricted production data
• High: Anything touching restricted data, anything that makes or influences a decision about quality, safety, pricing, or people

Low can be self-serve. Medium needs an approved tool. High needs a named owner, a human review step, and a record of what was used.

4. Vendor questions before anything gets approved

Before a tool goes on the register, get straight answers to a few questions:

• Does the vendor keep our prompts and files? For how long?
• Is our data used to train their models? Can we turn that off at the account level, not just per user?
• Can we enforce work-account sign-in with MFA?
• Where is the data stored and processed?
• If we do DoD work, does this tool meet the requirements for the data we plan to put in it?

If the vendor cannot answer clearly, that is your answer.

5. Human review and accountability

AI output is a draft, not a decision. Quotes, inspection results, customer replies, and anything that goes into a compliance record still need a person who owns it. Write that down. It protects your people as much as your customers.

A 30-day rollout that does not stall the plant

Week 1: Ask, do not accuse. A quick anonymous survey or a few floor conversations: what AI tools are you using, for what? You will learn more in a week than a firewall log will tell you in a year.

Week 2: Draft the data rules and the first version of the approved tool register. Pick a work-account option for the tools people clearly need so they have a safe lane on day one.

Week 3: Turn on the controls you already own. Work-account sign-in, MFA, data-sharing settings in the admin console, and blocking unapproved AI browser extensions on managed devices.

Week 4: Short training by role (front office, engineering, floor leads). Publish the request process. Set a 90-day review so the policy keeps up with new tools.

Where this fits with CMMC and NIST 800-171

If you are a DoD supplier, an AI policy is not a separate project. It is part of controlling where CUI goes. Unapproved AI tools are just another uncontrolled path for data to leave your boundary, the same as personal email or an unmanaged file share.

Your access control, media protection, and awareness training practices should cover AI use. When your SSP describes how CUI is handled, AI tools should not be a blind spot. For context on the current timeline and what still applies, see our CMMC overview, the NIST 800-171 overview, and The Manufacturer's Guide to NIST 800-171.

Start with the template, not a blank page

We built a free AI Governance Policy Template for exactly this. It covers data rules, an approved tool register, risk tiers, vendor questions, and a 30-day rollout, mapped to NIST AI RMF and ISO 42001. Edit it to fit your shop and you are most of the way there.

If you want to see where AI use sits alongside the rest of your security gaps, the free compliance readiness checklist is a good next step.

Bottom line

Your people are going to use AI. The only choice is whether they do it in tools you approved, with data rules they understand, or in tools you have never heard of with data you cannot get back.

A short, plain-language policy beats a ban every time. If you want a senior engineer to look at how AI and CUI are moving through your environment today, book a free 45-minute Compliance Gap Audit. You keep the written snapshot either way.