Somewhere in your supply chain, there is a decent chance this already happened: a supplier received your drawings, your specifications, maybe your entire technical data package — and someone on their team pasted the contents into an AI chatbot to draft the work instructions, inspection protocol, or process procedures for building your product. It probably saved them a day of writing. It may also have handed your intellectual property to a third party, violated your NDA, possibly broken federal export law, and produced a procedure that looks polished and is quietly wrong in two places.
Nobody meant any harm. That’s what makes this risk so easy to miss. The person who did it wasn’t stealing your design — they were trying to be efficient. But your data doesn’t care about intent, and neither does an auditor, a plaintiff’s attorney, or the State Department.
What’s actually at risk
Your confidential data just left the building. When proprietary drawings or specifications are pasted into a public AI tool, they are transmitted to a third party’s servers. Depending on the tool and the account tier, that data may be retained, reviewed by humans, or used to train future models. Most NDAs and supplier quality agreements were written before any of this existed — but nearly all of them prohibit disclosing confidential information to third parties, and an AI vendor is a third party. Worse, trade secret protection depends on demonstrating reasonable efforts to keep the secret. A design that has been fed into an AI model is a design whose “reasonable efforts” story now has a hole in it.
It may be an export violation. If the drawings describe an ITAR- or EAR-controlled item, uploading that technical data to a cloud AI service — with servers, staff, or model access that may sit outside the United States — can constitute an unauthorized export. No shipment required; transmitting controlled technical data to an uncontrolled system is enough. Defense and dual-use suppliers have spent years learning not to email controlled data to the wrong person, and a chatbot prompt is just a faster way to make the same mistake.
The output looks right, which is the problem. Large language models generate fluent, confident, professionally formatted text. They do not know your design intent, why that tolerance is tight, which characteristic is critical, or what the failure mode of the assembly is. An AI-drafted procedure can invert an operation sequence, invent a plausible-sounding process parameter, or silently drop the step that exists because of a complaint from 2019. A badly written human procedure usually looks badly written. A badly written AI procedure looks excellent — and that finish is exactly what gets it approved without the scrutiny it needs.
It punches holes in the quality system. Procedures and protocols are controlled documents. If they’re being generated by an uncontrolled tool, from an uncontrolled prompt, with no record of what was provided or what came back, the document trail behind your product now has a gap in it. For medical device suppliers, there’s a sharper edge: ISO 13485 §4.1.6 requires validation of software used in the quality management system, and a generative tool drafting your inspection protocols is awfully hard to argue out of that scope. And if your customer’s quality agreement requires approval before subcontracting or disclosing data — many do — an AI vendor in the middle of your documentation process starts to look a lot like an unapproved subcontractor.
If you’re the customer: control it like the flow-down it is
You cannot audit your way to certainty about what every supplier employee pastes into a browser. What you can do is make your expectations explicit, contractual, and checkable:
- Put AI in the quality agreement and the NDA. State plainly whether your data may be processed by AI tools at all, and if so, under what conditions — enterprise instances only, no training on inputs, no retention, disclosure and written approval first. Silence in the contract becomes permission in practice.
- Ask the question directly. Add AI use to supplier questionnaires, onboarding, and audit checklists: Do you use AI tools on customer data? Which ones? Under what agreements? Who approved them? A supplier who has never thought about the question is telling you something useful.
- Classify and mark what you send. Suppliers can’t protect what they don’t know is sensitive. Mark proprietary and export-controlled data as such, and send the minimum data package the job actually requires.
- Review supplier-generated documents like they matter. If a supplier builds procedures or inspection protocols from your specs, review and approve them against the source requirements — first article and process validation exist precisely to catch the plausible-but-wrong. This was always good practice; AI just raised the stakes.
- Treat AI governance as a selection criterion. A supplier with an AI use policy, an approved tool list, and trained staff is managing the risk. One who answers “our people don’t really use that stuff” almost certainly has people using that stuff.
If you’re the supplier: use the tools, but govern them
The answer is not a blanket ban — bans just push AI use into personal phones and private accounts, where you can’t see it. The answer is the same discipline you’d apply to any other process that touches customer property:
- Write an AI acceptable-use policy and mean it. Define which tools are approved, what data may and may not go into them, and who approves exceptions. Customer drawings, specifications, and anything export-controlled should sit firmly in the “not without written customer authorization” column.
- Use enterprise tools with the right contract terms. If AI is genuinely useful to your documentation process, procure it properly: agreements with no-training clauses, defined data retention, and appropriate data residency. A free consumer account is not a controlled process.
- Screen before you prompt. Make export-control and confidentiality screening a step that happens before data goes into any external system — AI or otherwise. If your team can’t tell whether a drawing is ITAR-controlled, that’s the problem to fix first.
- Keep a qualified human in the loop, formally. AI output is a draft, never a released document. Route every generated procedure through review and approval by someone competent in the process — inside your document control system, with the same rigor as anything else you release. Consider recording that AI was used and what inputs it received; your customer may ask, and “we don’t know” is the worst possible answer.
- Validate the tool if it’s in your QMS. If AI is producing quality system documents, treat it as QMS software: define its intended use, assess the risk, and validate accordingly. Frameworks like ISO/IEC 42001 exist for exactly this kind of governance, and being able to show one to a customer is rapidly becoming a competitive advantage rather than a burden.
- Train the people, not just the policy binder. The engineer pasting a spec into a chatbot at 4:45 on a Friday isn’t reading your policy in that moment. Training is what makes the pause happen — the split second of “wait, is this customer data?” that prevents the whole cascade.
The point underneath
Customer drawings and specifications are customer property — most quality standards say so explicitly, and every NDA assumes it. Handing that property to an AI tool is not categorically different from handing it to any other third party; it’s just newer, faster, and easier to do without thinking. The companies that will get this right aren’t the ones that ban the technology or the ones that ignore it. They’re the ones that treat AI like every other process capable of affecting product quality and confidentiality: defined, controlled, monitored, and owned by someone who signed their name to it.
Start with having a conversation with your supply chain today about how they are using AI and how they are protecting your data.