← Journal

Before pasting a CAD file into a chatbot, read EAR §734.18

· 7 min read · Written with an AI assistant

The US export rules treat properly end-to-end encrypted data as not an export. That carve-out was written with storage and transmission in mind. Before a controlled drawing goes into a hosted AI tool, it is worth asking what happens when th

An engineer has a drawing whose tolerance stack will not close, and drags the PDF into a general-purpose AI chatbot to ask why. If that drawing carries export-controlled technical data, the upload may itself be an export, and “it’s encrypted in the cloud” is not the answer many people assume it is.

The US export rules do contain an encryption carve-out. It is narrower than the phrase suggests. This piece walks through what EAR §734.18 and ITAR §120.54 say, where a hosted AI service sits against them, and the checks worth running before a part, drawing or spec leaves your network.

This is not legal advice. It covers US rules only. India runs its own export-control regime, which we have not researched for this piece. Treat it as a separate question for your compliance team.

Why a CAD file can be controlled data

The prompt feels like a question. The attachment is the payload. A STEP file carries geometry. A drawing carries dimensions, tolerances, material callouts and process notes. A specification carries performance requirements. Any of these can be technical data, and if you design parts for defence or aerospace work, some of them may be export-controlled.

Whether a given file is controlled is a classification decision made by people with that responsibility. It is not a gut call made at the moment of upload, and the chatbot does not make it for you. The habit to break is treating “just asking a question” as different from “sending the file”. To the regulation, the file is what matters.

What the encryption carve-out says

Start with the EAR. Under §734.18, BIS treats data that is properly secured with end-to-end encryption as not an export, and the definition of end-to-end encryption turns on the data never being in unencrypted form along the way (15 CFR §734.18, 2021 edition). The definition carries further conditions beyond that phrase. The edition cited here is from 2021, so read the current text on the eCFR before relying on any of it.

The practical effect, as one law firm summarised it, is that companies can store EAR-controlled software and technology on cloud servers in most countries without exporting it to those countries, provided it is secured with end-to-end encryption. When the EAR rule took effect, the ITAR had no matching change (Pillsbury).

The ITAR caught up later. On 26 December 2019 DDTC published an interim final rule, 84 FR 70887, effective 25 March 2020. It added §120.54, defining “activities that are not exports”, including a framework for properly secured encrypted technical data and the means of decrypting it (DDTC overview).

Before that rule, sending ITAR data outside the US needed a DDTC licence even when the transfer was secure and encrypted. The revised rule lets US companies send or store ITAR-controlled data overseas, for example on a cloud server, without one (Practical Law). Since 25 March 2020, unclassified defence technical data properly secured with end-to-end encryption is no longer treated as an export when sent outside the US, though the same commentary notes that some risks remain (Dinsmore).

The words carrying the weight are properly secured and end-to-end. Neither is a synonym for “the vendor says it’s encrypted”.

Storing a file is not the same as having it read

The carve-out was framed around storing and transmitting data. A cloud drive holding ciphertext never needs to understand what is inside the file. An AI service answering a question about your drawing is a different job. To tell you which tolerance in the chain is driving the stack, it has to work with the content.

That raises a question we are deliberately not answering: if a hosted service decrypts your file in order to process it, does the “never in unencrypted form along the way” condition still hold? Where is the decryption done, under whose control, in which country, and who or what can see the plain content? Take those questions to your export-control or compliance team. Encrypting the upload may not, on its own, put you inside the carve-out.

Two general AI risk frameworks point the same way, even though neither is about export control. The OWASP Top 10 for LLM Applications 2025 lists Sensitive Information Disclosure as LLM02:2025, second only to Prompt Injection (Invicti). NIST AI 600-1, the Generative AI Profile published in July 2024, extends the AI Risk Management Framework with 12 risk categories for generative AI. One is data privacy, covering leakage, unauthorised use, disclosure or de-anonymisation of data (Modulos).

Read them as checklists. Both treat what happens to data once it reaches a model as a primary risk to assess, not an edge case.

A worked example: one bracket drawing

Take a familiar case. You are reworking the hole pattern on a mounting bracket after a change request. The new pattern breaks a tolerance stack between the bracket and its mating plate. You have the drawing PDF, the STEP file and the customer’s material specification. The bracket goes into an assembly for a defence customer.

The tempting move is to upload the drawing and ask, “Which tolerance should I open up?” Before doing that, run four checks.

  1. Classify first. Look at the title block and any export marking. Check what the customer’s contract flowed down. If you do not know the classification, ask the person who owns it, and treat the file as controlled until they answer.
  2. Ask whether the file needs to go at all. A stack is a chain of dimensions and tolerances. You can often restate the problem in the abstract without the part. Whether even that is acceptable is your compliance team’s call, but it is a better starting point than the full drawing.
  3. Ask where the model runs. For any AI tool, get written answers to these questions:
    • Where is the file decrypted to be processed?
    • Which people, sub-processors and countries can access the decrypted content?
    • Is the content retained, logged or used for training?
    • Who holds the keys?
  4. Prefer a model inside your own environment. If the model runs on infrastructure you control, the decrypted file stays behind your own access controls. You still need classification and review, but the question changes from “what does the vendor do with it?” to “who in our organisation can see it?”

None of these checks is exotic. They are the same discipline you already apply to sending a drawing to a new supplier.

What this means for CAD and engineering tooling

For AI tools that work on engineering data, the export question is an architecture question. Where the model sits relative to the data decides which questions a customer’s compliance team has to answer. A tool that sends geometry to an external AI service inherits the storage-versus-processing question on every request.

That choice shaped how we are building AI-CAD, our engineering copilot for SOLIDWORKS. It runs on Bluecoderhub’s own fine-tuned, self-hosted model, with no external AI services, so CAD files and engineering data stay inside the customer’s environment. Specialist agents plan a change, SOLIDWORKS builds it, and an engineer approves every decision. AI-CAD is a prototype under active development; a prototype demo is planned for 30 November 2026 and a first pilot for January 2027.

To be clear about the limits: self-hosting does not make anyone export-compliant. It moves where the question is answered, onto infrastructure and access controls the customer already governs. Classification, access rules and compliance review still belong to the customer’s own people.

The encryption carve-out was a real change. It let controlled technical data sit on cloud servers without a licence. It was not written as a blanket pass for every service that touches a file. Before the next drawing goes into a chatbot, classify it, ask where it will be read, and put the hard question to the people who own export control. If you work through these questions in your own team, follow the journal or get in touch; we would like to hear how you are handling them.

Sources