Trade Secrets vs Cloud AI: A Guide For IP-Sensitive Businesses

A principal engineer at a Carlsbad aerospace supplier has a problem. Her team of thirty mechanical engineers want ChatGPT. They've seen what it does for code review, for writing specifications, for cleaning up technical documentation. They want it. She can't give it to them. Half their contracts are ITAR-controlled. The other half involve designs the company has spent fifteen years developing. Every prompt sent to a public model is, by the vendor's own terms of service, a prompt that may be retained, reviewed, and in some cases used to train future versions.

Her legal team's answer is the same answer every legal team is giving right now: no. No ChatGPT. No Copilot in the IDE. No Claude in the browser. Figure it out some other way.

The engineers find a way around it anyway. They always do.

The real problem isn't productivity. It's the leak you can't audit.

Public AI tools are extraordinary. They are also, from an IP perspective, a one-way mirror. You can see what you send in. You cannot see where it goes, who reviews it, which model it influences, or how it surfaces six months later when a competitor's engineer asks a similar question.

For most businesses, this is a theoretical concern. For IP-sensitive businesses it's an existential one. There are three categories where the risk is not theoretical:

Defense and defense-adjacent work. ITAR (International Traffic in Arms Regulations) and EAR (Export Administration Regulations) treat certain technical data the same way they treat the physical hardware it describes. Sending controlled technical data to a cloud service whose infrastructure includes foreign nationals, foreign data centers, or ambiguous retention policies is, in the plain reading of the regulations, an export. It doesn't matter that no one at the AI vendor read it. It doesn't matter that it was "just a code snippet." The compliance exposure is the same.

Biotech, pharma, and medical device. Compound structures, assay protocols, trial data, device firmware. HIPAA covers patient data, but trade secret law covers the research itself, and trade secret protection depends on the owner taking reasonable steps to keep it secret. Pasting a novel compound into a cloud chatbot is not a reasonable step.

Proprietary algorithms and robotics. Trading firms, autonomous systems companies, robotics startups, specialized software vendors. Here the IP is the code. The whole business is the code. Running that code through a third-party AI tool for "a quick review" is handing a photocopier to a competitor and hoping no one presses the button.

In all three cases, the legal review ends the same way. The lawyers say no, the engineers want it anyway, and productivity leaks out the sides in ways no one tracks.

Why the standard enterprise answers don't solve this

The AI vendors know this market exists. They've responded with a tier of offerings designed to look like a solution:

• "Enterprise" ChatGPT accounts with promises of no training on your data.
• Azure OpenAI and similar hyperscaler-hosted model endpoints.
• "Private" cloud deployments of commercial models inside a tenant.

These are real improvements over the free consumer tiers. For a lot of businesses they are the right answer. For IP-sensitive businesses they are not, for four specific reasons:

1. The data still leaves your facility. "No training" is a contractual promise, not a technical guarantee. For ITAR purposes, the data has still been exported the moment it hits the vendor's infrastructure. The regulation does not care whether the vendor pinky-swore not to look.

2. Audit evidence is weak. When a compliance auditor or a DCMA investigator asks where your controlled technical data went, "the vendor says they didn't retain it" is not the answer that keeps your contracts. On-premises systems can produce logs, access records, and air-gap documentation. SaaS cannot.

3. The attack surface is the entire internet. Every cloud AI service has had, or will have, a security incident. Prompt injection, session leaks, misrouted conversations, credential stuffing against admin consoles. Your trade secrets should not be one bad quarter at a vendor away from exposure.

4. The terms change. Today's "we don't train on your data" is tomorrow's acquisition, policy update, or quiet pricing-tier reshuffle. Infrastructure you own doesn't get re-licensed under new ownership.

What on-premises AI actually looks like

The alternative is not a research project. The open-model ecosystem has matured to the point where a well-specified on-premises system runs capable large language models — in the same performance class as recent commercial offerings — on hardware that sits in your server room, your SCIF, or a locked rack in your engineering wing.

A typical private AI deployment for an engineering team of 20 to 100 users looks like this:

• A GPU server sized to the models and the concurrency you need. For most engineering teams this is one or two machines, not a rack.
• Open-weight models (Llama, Mistral, Qwen, DeepSeek, and others) chosen for the specific tasks: code review, technical writing, document search, image analysis.
• A web interface for the chat workflow and API endpoints for integration into IDEs, document systems, and internal tools.
• Retrieval against your own document corpus — specifications, drawings, prior-art archives, codebases — so the model answers from your actual institutional knowledge instead of generic internet-trained guesses.
• Network isolation on its own VLAN, with no outbound internet access from the AI subnet. The model doesn't call home because it has no way to call home.
• Full audit logging of every prompt, every response, every user. If the compliance team asks, you have records.

The whole thing lives on your network. The data never leaves. There is no vendor to breach, no terms of service to re-read every quarter, no "did someone paste the wrong thing into the wrong window" question hanging over the engineering floor.

What the engineering team actually gets

The point of all this isn't security theater. It's giving the engineering team the productivity tools their competitors are already using, without the exposure.

Specifically:

1. Code review that understands your codebase. A private model with retrieval over your repository knows your naming conventions, your internal libraries, your architectural patterns. It catches things a cloud model can't, because the cloud model has never seen your code. And it reviews code that could never legally go to a cloud model in the first place.

2. Technical writing assistance on controlled documents. Specifications, test reports, proposals, white papers. The engineers draft, the model cleans up, nothing crosses the facility boundary. For ITAR-controlled proposal work this is the difference between "the AI tools are forbidden" and "the AI tools are standard."

3. Design analysis and tradeoff reasoning. Feeding a model your actual design constraints — thermal budgets, material properties, prior test data — and asking it to reason about alternatives. On a public model this is a direct leak of your competitive position. On a private model it's a Tuesday.

4. Searchable institutional memory. Fifteen years of engineering drawings, test reports, email threads from retired principal engineers. A private model with retrieval turns that archive into something the current team can actually query in plain English. The knowledge stops walking out the door when senior engineers retire.

5. Prompt freedom. This one is cultural more than technical. When engineers know the system is private, they ask the questions they actually need to ask. On a cloud tool they self-censor — they generalize the problem, strip out identifiers, phrase around the sensitive parts. That self-censoring is also the thing that makes the AI less useful. Remove the fear and the tool starts earning its keep.

The compliance posture, in one sentence

A properly deployed on-premises AI system means your answer to the next ITAR audit, the next trade-secret clause in a customer contract, or the next question from your own legal team is: the data does not leave this facility, we have logs that prove it, and here is the network diagram.

That is a different conversation than the one most businesses are currently having with their lawyers about AI.

Who this is for

This isn't the right answer for every business. A marketing agency that wants to speed up blog drafts should use the commercial tools. A general accounting firm should use the commercial tools. The economics of private AI only work when the data itself has real competitive or regulatory weight.

But if you're running a defense supplier in Carlsbad, a biotech on the Torrey Pines mesa, a robotics company in Sorrento Valley, a trading desk anywhere, or a specialized software firm whose algorithms are the whole company — the math is different. The productivity gap between teams with AI and teams without it is widening by the quarter. Pretending your engineers will stay productive without the tools their peers have is wishful thinking. Letting them use cloud tools against policy is worse.

Build the capability inside the fence. SentriCraft's business practice deploys private AI on hardware you own, on networks we design and manage, with audit logs and isolation documented from day one. The engineers get the tool. The lawyers get the posture. The trade secrets stay where they belong.

A network isn't infrastructure you rent from somewhere else. Neither is the intelligence you run on top of it.