Ask a plant manager what keeps them up at night about a new software tool, and data breach is rarely the first answer — it is usually somewhere further down the list, behind downtime, behind a supplier missing a quality spec, behind a customer audit. That instinct is not wrong, exactly, but it misses something specific to manufacturing that does not apply in most other industries: a meaningful share of the documentation flowing through an ordinary engineering department is not merely confidential in the commercial sense. It is legally controlled technical data, and moving it carelessly can constitute a regulatory violation entirely independent of whether any competitor or adversary ever actually benefits from the exposure. The violation exists the moment the data crosses a line the statute drew, regardless of consequence.
1. Export-Controlled Technical Data
The International Traffic in Arms Regulations, commonly abbreviated ITAR, govern technical data related to defense articles — not just the physical hardware itself, but the drawings, specifications, and technical know-how that would allow someone to design, build, or modify it. The Export Administration Regulations, or EAR, cover a broader and in some ways more common category: dual-use items with both civilian and military applications, which describes an enormous share of ordinary industrial and electronic components that manufacturers handle every day without necessarily thinking of them as "controlled" in any special sense.
Both regimes restrict not just the physical export of an item across a border but the transmission of associated technical data by any means — including electronic transmission to systems or personnel located outside the United States, or even to foreign nationals physically present inside the United States, a category the regulations treat, for these purposes, as equivalent to an export to their home country. This is the detail that most engineers, trained to think about export control in terms of shipping manifests and customs declarations, simply have not internalized: an email attachment can be an export. A cloud upload can be an export. The physical location of the recipient's body is, in many cases, entirely beside the point.
2. The Cloud Jurisdiction Problem
This creates a distinct and frequently underappreciated risk: routing export-controlled technical data through a general-purpose cloud AI service can itself constitute an unauthorized export, if the service's infrastructure, support personnel, or model-training pipeline touches foreign persons or foreign-located servers at any point in the chain — regardless of whether any human being downstream ever actually reads, uses, or acts on the output the AI system produced. This is the concept of a "deemed export," and it can occur through data access alone. The regulatory violation is complete the moment a foreign person gains the technical capability to access the controlled data, whether or not they exercise it.
Most cloud AI vendors, understandably, do not publish a detailed map of exactly which support engineers in which countries could theoretically access customer data during a troubleshooting session, or exactly where model-training infrastructure is physically located and staffed. That opacity is not evidence of bad faith on the vendor's part — it reflects how modern cloud infrastructure is actually built, distributed and redundant by design — but it is precisely the opacity that makes it very difficult for a manufacturer to make an informed export-control judgment about whether a given cloud service is safe to use with a specific category of controlled technical data. Absent that visibility, the only defensible assumption is a conservative one.
3. Controlled Unclassified Information in the Civilian Supply Chain
Even manufacturers with no direct defense contract of their own increasingly inherit NIST SP 800-171 obligations through customer flow-down clauses, as controlled information moves down multi-tier supply chains from a prime contractor through several layers of subcontractors and suppliers, each one bound by the same contractual language as the one above it. A workflow automation tool touching supplier correspondence, bill-of-materials data, or engineering change orders may be squarely in scope for these obligations without the manufacturer having a direct government contract at all — the obligation flowed down through a commercial customer relationship that may not have felt, at the time it was signed, like a defense-adjacent contract in any meaningful sense.
This tends to catch smaller suppliers by surprise more than larger primes, precisely because smaller suppliers are less likely to have a dedicated compliance function tracking which of their customer contracts carry CUI flow-down language buried in the terms and conditions. A supplier making a component that ends up, several tiers removed, in a piece of defense equipment may not think of itself as part of the defense industrial base at all — and yet the flow-down clause in its purchase order says otherwise, and that clause governs regardless of the supplier's own self-perception.
4. Architecture as the Practical Answer
A fully on-premises or edge deployment keeps technical data inside the facility's own network boundary entirely, which avoids the export-jurisdiction question at the architecture level rather than attempting to manage it after the fact through downstream access controls, employee attestations, and periodic monitoring that depends on catching a violation after it has already occurred. If the data never leaves the facility's network, and the processing infrastructure is staffed and physically located entirely within the United States, the "deemed export through cloud access" problem simply does not have the opportunity to arise for that workflow.
For non-controlled, lower-sensitivity workflows — general supplier correspondence that contains no technical specifications, non-technical scheduling, routine administrative communication — a masked secure-cloud deployment remains entirely appropriate and considerably faster and cheaper to stand up than building or expanding local infrastructure for every use case. The discipline required is not "avoid the cloud everywhere," which would sacrifice real efficiency gains for no corresponding benefit on genuinely non-sensitive workflows — it is classifying each workflow's data honestly before choosing its deployment path, and being willing to revisit that classification as a workflow's scope expands.
5. Building the Classification Habit on the Factory Floor
The practical challenge in manufacturing is less about understanding the regulations in the abstract — export-control officers generally understand ITAR and EAR quite well — and more about getting that understanding embedded into the daily habits of engineers and program managers who are not export-control specialists and are not thinking about jurisdiction when they are trying to close out a design review by end of day. The engineer uploading a drawing to get a quick AI-generated summary is not weighing deemed-export risk in that moment; they are trying to hit a deadline.
This is exactly the argument for building the compliant boundary into the tooling itself, rather than into a training program that depends on every engineer remembering an export-control rule in the middle of an unrelated task. If the sanctioned workflow automation tool for engineering documentation runs entirely on-premises by default, the engineer does not need to make an export-control judgment call at all in order to use it safely — the safe choice and the convenient choice are the same choice, which is the only version of a compliance program that reliably survives contact with a real production schedule.
6. Conclusion
For manufacturers, the deployment-model decision is not primarily a data-breach question in the way it might be for a retailer or a consumer app — it is an export-control question, governed by an entirely different body of statute, with entirely different consequences that do not require any data breach to occur at all. Matching architecture to data classification, workflow by workflow, and building that match into the default behavior of the tools engineers actually use, is the only approach that scales safely across a supply chain of genuinely mixed sensitivity.