Using AI on DoW Work: Technical Data, DFARS Data Rights, and CUI Safeguards

Defense contractors, especially small and mid-sized companies without a dedicated compliance team, are increasingly using generative AI tools, large language models (LLMs), and AI coding assistants to accelerate engineering, software development, proposal drafting, and internal operations. The productivity gains are real. So are the risks.

Most contractors are not intentionally uploading sensitive information into inappropriate systems. Problems usually arise when engineers, software developers, or program managers use AI tools the same way they use search engines, collaboration platforms, or cloud storage without recognizing the legal significance of the information being shared.

For defense contractors, those risks generally fall into three broad categories. First, AI use can create compliance issues when Controlled Unclassified Information (CUI), Covered Defense Information (CDI), or other protected information is processed in environments that do not satisfy contractual or regulatory requirements. Second, AI use can affect intellectual property rights, including trade secret protection, DFARS data-rights assertions, patent rights, and software licensing obligations. Third, AI tools can create export-control concerns when technical data subject to ITAR or EAR restrictions is processed by unauthorized systems or personnel.

The key question is no longer whether defense contractors will use AI. Most already do. The real question is whether they can obtain the benefits of AI without creating compliance problems, weakening intellectual-property protections, or triggering export-control concerns.

The AI Data Ingestion Risk: Prompts, Inference, and Model Training

Running technical data through commercial AI tools creates exposure at three distinct operational layers:

1. Prompt & Context Ingestion: Prompts containing source code, CAD files, or system architecture documents are transmitted to the provider's servers, which may sit outside the contractor's security boundary.

2. Inference & Cache Retention: Many providers log prompts and outputs for a period of time for abuse monitoring, quality control, or troubleshooting.

3. Model Fine-Tuning & Training: Depending on the service tier and terms of use, some providers may use inputs to improve their models. Consumer and free tiers are the biggest concern, and their terms can change. Enterprise agreements with zero-data-retention (ZDR) terms and training opt-outs reduce this risk considerably.

When a contractor feeds CUI into a tool that doesn't meet its DFARS safeguarding requirements, it's no longer just a policy issue. It can be a contract compliance problem and, depending on the facts, a reportable cyber incident.

In practice, the legal issues created by AI rarely surface at the moment information is uploaded. More often, they appear months, or even years, later when a contractor is preparing a patent application, defending a restrictive marking, responding to a compliance review, conducting a due-diligence exercise, or investigating a potential data spill. The challenge is that a seemingly routine AI interaction can create consequences across multiple legal disciplines at the same time.

DFARS Data Rights and Commercial AI Processing

Under DoD contracts, the government's license rights in technical data and computer software depend mostly on how the item was developed and paid for. Contractors protect those rights through assertions and proper markings. Bringing AI tools into software development and engineering workflows complicates both the funding record and the confidentiality of the data.

DFARS 252.227-7013 & 7014: Technical Data and Computer Software

Under DFARS 252.227-7013 (noncommercial technical data) and DFARS 252.227-7014 (noncommercial computer software), the government generally receives Unlimited Rights when development was funded by the government, Government Purpose Rights when development used mixed funding, and Limited Rights (technical data) or Restricted Rights (software) when development occurred exclusively at private expense. Government Purpose Rights typically convert to Unlimited Rights after five years unless the parties negotiate a different period.

Processing private-expense technical data through a public or shared AI tool creates two legal risks:

• Loss of Trade Secret Status: If proprietary source code or design data is disclosed through an AI tool without adequate confidentiality protections, the contractor risks losing trade secret protection. Courts look at whether the owner took reasonable measures to keep the information secret, and uncontrolled AI use makes that harder to show.

• Expanded Government Rights: Limited and Restricted Rights depend on funding, not on secrecy alone. Under DFARS 252.227-7013 and 252.227-7014, though, the government gets unlimited rights in technical data or software that a contractor has released or disclosed without restrictions on further use, release, or disclosure. An AI service whose terms let the provider use, retain, or share your inputs is a poor fit for data you intend to protect, so read those terms before engineers paste anything in. Uncontrolled AI processing also blurs the development record contractors need if the government challenges a restrictive marking.

DFARS 252.227-7015: Commercial Technical Data

For commercial products and dual-use technologies, DFARS 252.227-7015 limits the government to using commercial technical data within the government. The government can't use that data to manufacture additional quantities of the product, and it can't release the data outside the government without the contractor's written permission, except in narrow cases such as emergency repair or overhaul and covered government support contractors. Commercial computer software is acquired under the license customarily provided to the public (DFARS 227.7202-3). Those protections only help if the data stays confidential. Sending commercial design files through a third-party AI service may also breach the contractor's NDAs or license agreements with commercial partners, depending on their terms.

Data Rights in AI Models, Training Data, and Outputs

Neither 7013 nor 7014 mentions AI models by name, but the existing framework still applies. Model weights, training code, and inference software are likely to be treated as computer software or technical data under the DFARS definitions. That means the government's rights in a model developed under a DoD contract will generally depend on how its development was funded, just like any other software deliverable.

A few practical points follow:

• Training Data: If government-furnished or government-funded data is used to train or fine-tune a model, expect the government to argue that the resulting model was developed at least partly at government expense. Keep government-funded and private-expense training pipelines separate and documented.

• AI-Generated Outputs: Markings protect rights a contractor already has. They can't create rights the contractor doesn't have. Code or documents generated with AI assistance still need a funding analysis before they're marked and delivered.

• Copyright and Open Source: Under the U.S. Copyright Office's January 2025 report on copyrightability, purely AI-generated material isn't protected by copyright unless a human exercised sufficient control over its expressive elements, and prompts alone aren't enough. AI coding assistants can also reproduce open-source code that carries its own license obligations. Both belong in any IP review before delivery.

• SBIR and STTR Awards: Small businesses working under an SBIR or STTR award should note that DFARS 252.227-7018 governs their data rights instead of 7013 and 7014. The same funding and marking discipline applies to any AI models or code developed under those awards.

Patent Risks in AI-Assisted Engineering

AI tools raise three patent issues that defense contractors often overlook:

• First, only natural persons can be named as inventors. The USPTO's November 2025 revised inventorship guidance treats AI systems as tools and applies the same conception standard to every invention, so engineers should keep good records of their own conception, just as they would for any other invention.
• Second, entering invention details into a third-party AI tool before a patent application is filed raises confidentiality questions that can complicate both novelty and trade secret protection.
• Third, if an AI-assisted invention is conceived or first actually reduced to practice in the performance of a funded contract, it may be a subject invention, and the contract's invention disclosure, election, and reporting deadlines still apply. Missing them can put title to the invention at risk.

Prime contractors often add their own restrictions too. Many subcontracts and NDAs limit which third-party tools a subcontractor may use with the prime's data, so check those terms before rolling out AI tools on a program.

CUI Compliance, NIST SP 800-171, and CMMC Requirements

Covered Defense Information (CDI) is CUI that DoD provides to a contractor, or that the contractor develops or handles in support of contract performance. When DFARS 252.204-7012 (Safeguarding Covered Defense Information and Cyber Incident Reporting) is in the contract, CDI must be safeguarded under that clause. Primes must flow the clause down to subcontractors whose work involves CDI, so a small subcontractor can carry the same obligations as the prime.

FedRAMP Requirements for Cloud AI

DFARS 252.204-7012(b)(2)(ii)(D) requires that a cloud service provider used to store, process, or transmit CDI meet security requirements equivalent to the FedRAMP Moderate baseline and comply with the clause's requirements for incident reporting, malicious software, media preservation, and forensic access. A DoD CIO memo issued in December 2023 sets a high bar for "equivalent," so the simplest path is an offering listed as FedRAMP Moderate or High authorized on the FedRAMP Marketplace. Some programs impose stricter requirements by contract. Consumer and standard commercial tiers of AI tools generally aren't FedRAMP authorized. Several providers now offer government-authorized versions, and FedRAMP authorization attaches to a specific cloud service offering, not to every product or feature a vendor sells. The real question isn't which brand a team uses but which specific offering, under which terms. DoD's CMMC guidance also makes clear that encrypting CUI doesn't remove the FedRAMP requirement.

Putting CUI into an unauthorized tool can implicate several NIST SP 800-171 Rev. 2 requirements:

• Requirement 3.1.3 (Flow of CUI): Controlling the flow of CUI in accordance with approved authorizations.

• Requirement 3.1.20 (External Systems): Verifying and controlling or limiting connections to and use of external systems, which NIST's discussion says includes using cloud services to process, store, or transmit CUI.

• Requirement 3.13.1 (Boundary Protection): Monitoring, controlling, and protecting communications at the system's external boundaries.

A CUI spill into an unauthorized AI tool should also be evaluated as a potential cyber incident. DFARS 252.204-7012 requires contractors to rapidly report cyber incidents affecting covered defense information, which the clause defines as within 72 hours of discovery, and to preserve images of affected systems for at least 90 days.

Cybersecurity Maturity Model Certification (CMMC)

On July 13, 2026, the Department of War suspended Phase 2 of the CMMC program, which would have made third-party (C3PAO) Level 2 certification a condition of award for most contracts involving CUI starting November 10, 2026. DFARS Class Deviation 2026-O0025, Revision 3, signed September 3, 2026, directs contracting officers to remove or revise third-party CMMC requirements in solicitations and contracts while a CMMC Reform Task Force reviews the program. As of this writing, the Task Force's recommendations haven't been made public.

The underlying obligations didn't pause. The deviation itself requires baseline compliance with NIST SP 800-171 Rev. 2 under DFARS 252.204-7012, and Level 1 and Level 2 self-assessments, SPRS scores, and annual affirmations remain in place. Primes may also keep their own supplier requirements, so subcontractors should confirm what their primes expect. For AI tools, a cloud AI service that stores, processes, or transmits CUI falls within the contractor's assessment scope, and the CMMC program rule (32 CFR 170.19) requires external service providers to be documented in the System Security Plan (SSP). An undocumented AI tool handling CUI can leave requirements NOT MET in a self-assessment, and an inaccurate SPRS score or affirmation carries False Claims Act risk. DOJ has continued to settle cyber-related False Claims Act cases during the suspension.

ITAR and EAR Export Control Liabilities in AI Engineering

Defense software, aerospace engineering specifications, and dual-use hardware designs are frequently subject to the International Traffic in Arms Regulations (ITAR, 22 CFR Parts 120-130) or the Export Administration Regulations (EAR, 15 CFR Parts 730-774).

• Server Location and Foreign Access: Depending on the service and its configuration, AI requests may be processed in data centers outside the United States, and provider personnel with access may include foreign persons. Processing ITAR-controlled technical data through infrastructure that isn't restricted to U.S. locations and U.S. persons risks an unauthorized export, which can carry civil and criminal penalties under 22 U.S.C. 2778. The ITAR excludes from the definition of export the sending or storing of unclassified technical data that is end-to-end encrypted with FIPS 140-2 compliant (or comparable) cryptography and isn't intentionally sent to or stored in a proscribed country (22 CFR 120.54(a)(5)). An AI service generally has to decrypt prompts to process them, and the exception requires that the means of decryption not be provided to any third party, so contractors shouldn't assume it covers AI use.

• Model Weight Contamination: If ITAR-controlled source code or technical data is used to fine-tune an AI model, the resulting model itself may be treated as controlled technical data subject to export restrictions.

A Common AI Scenario

Consider a small defense contractor developing autonomous drone-navigation software under a combination of private funding and Department of Defense contract funding.

An engineer encounters a software bug and copies several hundred lines of source code and system architecture notes into an AI coding assistant. The engineer receives a useful answer and fixes the issue within minutes.

Months later, the contractor discovers that the uploaded information included proprietary software, potentially controlled technical data, and information associated with a government program. What initially appeared to be a routine engineering task now raises questions about cybersecurity compliance, trade secret protection, DFARS data rights, and possibly export controls.

The problem is not the use of AI itself. The problem is using AI without first understanding what information is being provided to the system and how that information will be handled.

Actionable Risk Protocol for Defense Tech Contractors

To capture AI productivity gains without risking CUI spillage, weakening data rights, or compromising patent protection, defense contractors should put the following protocols in place. Steps 4 and 5 cost little and are the best place for smaller companies to start:

1. Deploy Isolated Enterprise/GovCloud AI Instances

Restrict defense-related AI work involving CUI or export-controlled data to environments that meet DFARS 252.204-7012 cloud requirements (FedRAMP Moderate equivalent or higher), such as government cloud AI offerings from major cloud providers, with:

• Zero Data Retention (ZDR) for prompts and completions

• Contractual opt-outs preventing model fine-tuning or training on user inputs.

• U.S. persons-only physical and logical access controls where export-controlled data is involved.

Many small contractors already run email and file storage in a FedRAMP-authorized government cloud environment. Before turning on an AI assistant inside that environment, confirm the AI feature itself is covered by the authorization, since authorization covers a specific offering and new features aren't automatically included.

2. Implement Automated Pre-Inference Scrubbing

Integrate local, client-side DLP (Data Loss Prevention) tools that screen prompts before they leave the corporate network. These tools should flag and block:

• CUI markings (e.g., CUI//FEDCON, DISTRIBUTION STATEMENT B/C/D/E/F).

• Proprietary source code headers and

• Trade secret notices.

• ITAR/EAR export control markings.

3. Establish Clear DFARS Marking Protocols

Keep commercial, private-expense codebases separate from government-funded software modifications, and document the funding source for each. Make sure all AI-generated or AI-assisted code goes through IP review, including a funding analysis and an open-source license check, and receives proper restrictive legends before delivery to a prime contractor or the government. Software delivered without restrictive markings is presumed to come with unlimited rights (DFARS 227.7203-10), and the government has no liability for releasing unmarked commercial technical data (DFARS 252.227-7015(e)). Marking is the step small companies most often skip, and it's the hardest to fix later.

4. Adopt a Short, Written AI Use Policy

Most small and mid-sized contractors don't need a long policy. A one- or two-page document that lists approved tools, says what data can and can't go into them, and names who to call when something goes wrong covers most of the risk. Train engineers on it and keep a record of the training. NIST SP 800-171 already requires security awareness training (requirements 3.2.1 and 3.2.2), so this can fold into training you're already doing.

5. Check Your Contracts and Flow-Downs Before Rolling Out AI

Before approving an AI tool for program work, check three things: whether the contract or subcontract includes DFARS 252.204-7012 or a CMMC level requirement, whether your prime's subcontract terms or NDAs restrict third-party tools, and whether any of the data is export controlled. A quick review up front costs far less than cleaning up a spill or defending a challenged marking later.

Conclusion

Artificial intelligence is rapidly becoming another standard tool in the engineering and software-development toolbox. Most defense contractors will use it in some form, and many already do.

The question is not whether AI should be used. The better question is whether contractors understand what information they are providing to AI systems and what obligations attach to that information. A source-code repository, technical drawing, invention disclosure, software design document, or system architecture diagram may carry cybersecurity requirements, intellectual-property implications, export-control restrictions, or all three at once.

Contractors that approach AI with the same discipline they already apply to patents, trade secrets, technical data rights, and controlled information will generally be able to capture the benefits without taking unnecessary risk. Contractors that treat AI as merely another productivity tool may discover the consequences only later, during a compliance review, government audit, patent filing, due-diligence process, or data-rights dispute.

The objective is not to avoid AI. The objective is to use it deliberately, with an understanding of how compliance obligations, intellectual-property rights, and export-control restrictions apply to the underlying information being processed. Contractors that establish those guardrails early will be in a far stronger position as AI becomes increasingly integrated into defense-sector operations.

For tailored legal counsel on Department of Defense / Department of War (DoD/DoW) IP protection, technical data rights, and commercial-to-defense strategy, explore the capabilities of our Aerospace & Defense Practice Group and Intellectual Property & Technology Transactions Practice. To evaluate your AI data rights, trade secret protections, or patent strategy, contact Matthew J. May, Chair of the Aerospace & Defense Practice Group.