Does Using AI Put Trade Secrets At Risk? (Video)

If you are a Navy contractor, ship repair company, or defense supplier wondering whether using AI puts trade secrets at risk, you are asking exactly the right question. I see why this concern is growing. Federal agencies now operate under formal AI governance and acquisition guidance, which means contractors should expect more questions about oversight, documentation, and how AI-assisted decisions are made.

My short answer is this: AI itself does not automatically hand your trade secrets to the government. The real risk usually comes from contract language, deliverable definitions, disclosure obligations, vendor terms, data handling, and how your team responds when the government asks for an explanation. That is where contractors can lose control of valuable methods without realizing it until the project is already underway.

In my view, the better question is not simply whether using AI puts trade secrets at risk. The better question is what part of your workflow could turn an internal advantage into something you are forced to disclose, deliver, or defend. When I look at this issue, I focus on the contract first, then the data, then the process.

^{#GovernmentContracts #ArtificialIntelligence #NavyContracts #ShipRepair #DefenseIndustry #FederalContracts #TradeSecrets #AICompliance #industriallawyer #insurancelawyer #commericallitigation #privacylaw #datasecuritylaw #whitecollardefense #defenselaw #classactionlawsuits #AIlawsuits #AIdatabreach}

Does using AI put trade secrets at risk by itself?

Trade secret law can protect valuable business and technical information, including internal methods, processes, programs, planning systems, and engineering know-how, as long as that information is actually treated as confidential. That can include scheduling logic, labor forecasting assumptions, optimization rules, and internal AI-supported workflows that give a contractor a competitive advantage.

The key point is that using AI alone does not automatically mean those protections disappear. If a contractor uses AI as an internal tool to help perform work, that does not automatically transfer the underlying model, logic, or proprietary process to the government. The more important question is what the contract requires the contractor to deliver or explain. If the contract is vague about AI outputs, transparency, or explainability, that is where the real risk begins. In other words, the problem is usually not the use of AI itself, but rather that it is unclear contract language that can blur the line between the final work product and the protected internal methods behind it.

Where the real exposure begins

The real exposure usually starts with vague drafting. If a contract requires a schedule, a forecast, a recommendation, or a report, that sounds straightforward. But once a clause starts using broad phrases like AI outputs, explainability, transparency, validation materials, model documentation, or auditable decision support, the scope can widen quickly. Federal AI acquisition and governance memoranda have pushed agencies to strengthen risk management and visibility into AI systems, so contractors should expect more scrutiny around how AI-assisted outputs are generated and controlled.

Now that doesn’t mean the government automatically owns your internal methods. However, sloppy definitions can create leverage for broader disclosure requests. When explainability is undefined, a request for an explanation can turn into pressure to reveal assumptions, weighting, workflow logic, source inputs, or other confidential details that give your company its advantage. That is the moment when using AI becomes a practical contract problem instead of a theoretical one.

Why this matters so much on Navy work

Navy and ship repair work is especially sensitive because competitive advantage often lives inside the process rather than the final paper you hand over.

A schedule may look simple on the surface. But behind that schedule may be years of institutional knowledge about drydock congestion, supplier slippage, rework patterns, labor efficiency, overtime impact, sequencing risk, and how to compress an availability without creating failure elsewhere. If an internal AI-assisted tool helps your team turn that experience into better performance, the trade secret value often sits in the method, not just the final output. Under trade secret law, that kind of technical and business process information can qualify for protection when properly safeguarded.

That is why I don’t tell contractors to stop using AI. I tell them to define the boundary between the deliverable and the engine that produced it. If that boundary is not clearly drawn, using AI can shift from a smart business question to an expensive dispute.

A real-world example contractors should recognize

Imagine a ship repair contractor managing overlapping availabilities across limited drydock space. The company uses an internal AI-assisted scheduling tool trained on its own proprietary historical labor patterns, supplier reliability data, rework history, and sequencing behavior. The contract requires the contractor to deliver an updated schedule, and that is exactly what the contractor provides.

At that stage, the issue is not simply that AI was used. The more important question is whether the contract clearly defines what must be delivered and what must be explained. Problems can start when performance pressure builds, and the government wants to know why one availability was sequenced ahead of another. If the contract includes broad or unclear language about AI transparency or explainability, the discussion can quickly move beyond the final schedule and into assumptions, scenario testing, internal weighting, or decision-making logic that the contractor never intended to disclose.

That is how this risk often develops in practice. It isn’t because AI automatically strips away protection. Unclear contract language can blur the line between the final work product and the proprietary methods behind it.

What general counsel and contract teams should do now

1. Map where AI is actually being used

You cannot protect what you have not identified. Many companies discover too late that program teams are already using AI in scheduling, forecasting, logistics, quoting, maintenance planning, document review, or reporting. Start with visibility. Determine what tools are in use, what data they touch, and whether any output is flowing into a contract deliverable. Recent federal AI guidance makes visibility and risk management a practical necessity, not just a governance exercise.

2. Define deliverables with precision

Be explicit about what the government receives and what remains internal. If your AI system is merely an internal support tool, the contract should say so where possible. If only the final schedule, report, or recommendation is deliverable, define that clearly.

3. Control explainability before it controls you

I encourage contractors to prepare an explanation framework that describes outcomes without disclosing proprietary logic. That may include business justification, process summaries, validation results, or performance metrics that answer the government’s concern without exposing the underlying method. In many disputes, the problem is not that an explanation was required. The problem is that no one defined the safe level of explanation in advance.

4. Mark and segregate proprietary data

If your company is going to assert limitations, it needs disciplined marking, clean documentation, and a process to support those assertions. Also, separate government data from proprietary training data wherever possible. If you blend everything together carelessly, you invite arguments later about rights, access, and scope.

5. Review vendor terms before adoption, not after a dispute

Your internal AI tool may not be as internal as you think if the vendor retains broad rights, stores prompts indefinitely, uses input for training, or imposes weak confidentiality terms. That is a trade secret issue and a contract risk issue.

6. Train program managers to stop oversharing

A surprising number of disclosure problems begin in meetings, status calls, slide decks, white papers, or well-intentioned technical explanations. If your team does not know the line between explaining a result and revealing a protected method, it’s much more likely that using AI can put trade secrets at risk. Internal training matters. So does a clear escalation path for disclosure questions.

The questions contractors are already asking

Does using AI put trade secrets at risk on a government contract?

It can, but not automatically. The main risk comes from what the contract requires you to deliver, disclose, validate, or explain, along with how well you protect secrecy in practice.

If I use AI in scheduling, does the Navy own my model?

Usually not just because you used it. Ownership and license rights depend on the contract, the applicable clauses, the source of development funding, and whether the software or technical data are actually delivered.

What counts as a trade secret in an AI workflow?

Potentially, your training approach, source code, prompts, assumptions, workflows, data curation methods, weighting logic, decision rules, or process architecture, if they derive value from secrecy, and you take reasonable steps to protect them.

Can explainability requirements force disclosure of proprietary logic?

They can if the contract language is broad and your company has not set boundaries around what explanation means. That is why precise drafting matters so much.

What is the safest first step for a contractor using AI today?

Do a contract and workflow review before the next proposal, modification, or deliverable cycle. That is the best time to narrow definitions, strengthen markings, and fix data practices before a dispute starts.

Protect the advantage before the contract gives it away

For contractors, the most useful answer to whether using AI puts trade secrets at risk is this: AI is not the automatic transfer event. Bad definitions, weak controls, careless disclosures, and unmanaged contract language are.

That is why I would treat AI workflows the same way I would treat any other valuable technical edge. Identify them. Protect them. Define them carefully in the contract. Control how they are explained. Keep your proprietary data cleanly separated. And do not assume that a smart internal tool will stay protected if your paperwork and process say otherwise.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.