Can You Use AI Tools If You Handle CUI?

I get this question more than any other right now, and it usually arrives in a slightly panicked tone: “We handle CUI. Are we allowed to use AI at all?”

The short answer is yes. The Department of War is deploying commercial AI to roughly three million people as I write this. Nobody is telling you to unplug.

But “are we allowed to use AI” is the wrong question, and asking it that way is how small contractors end up in trouble. The rules do not care whether a tool is artificial intelligence. They care where your data goes, who can read it, and whether you can prove any of that to an assessor or a prosecutor. AI is not a new category of risk. It is an unusually fast way to move CUI somewhere it should not be.

This post is about that risk — the liability, not the tooling. If you want the tool-by-tool rundown of what is actually authorized, that is a separate post and I will link it when it goes up.

The rule that governs this is not an AI rule

DFARS 252.204-7012 has been in your contracts for years. The paragraph that matters here is (b)(2)(ii)(D):

“If the Contractor intends to use an external cloud service provider to store, process, or transmit any covered defense information in performance of this contract, the Contractor shall require and ensure that the cloud service provider meets security requirements equivalent to those established by the Government for the Federal Risk and Authorization Management Program (FedRAMP) Moderate baseline.”

Read it again and notice what it does not say. It does not say “chatbot.” It does not say “artificial intelligence.” It does not carve anything out. It says store, process, or transmit on an external cloud service provider.

A commercial AI assistant is on-demand network access to a shared pool of computing resources somebody else owns. When your engineer pastes a paragraph of controlled technical information into it, that paragraph is transmitted to it, processed by it, and — on the consumer tiers, which I will get to — stored by it. That is three for three.

So the obligation is not new and it is not exotic. It is the same cloud rule you already have to satisfy for your email, your file share, and your ticketing system. The only thing that changed is how easy it became for one employee to trigger it in four seconds without telling anybody.

The government has now said this out loud

For a long time the honest answer to “has anyone in the government actually addressed AI and CUI directly?” was no. That changed on March 30, 2026, when the Information Security Oversight Office — the CUI Executive Agent, the office that owns the CUI program government-wide — issued ISOO Notice 2026-01. The operative sentence:

“If an AI system is Internet-enabled, connected to infrastructure that is external to the agency’s control, or otherwise connected to environments that are not accredited for the handling of classified information or that meet the standards for protection of CUI, it is prohibited for agency personnel to input classified information or CUI on such systems.”

I want to be careful here, because I have seen this notice already being oversold. It is addressed to agency personnel. It does not, by its own terms, bind you as a contractor, and it contains no contractor obligations and no spillage procedures. Your binding obligations run through your contract clauses.

But it is written by the office that defines what protecting CUI means. If you are ever standing in front of an assessor, a contracting officer, or a Civil Division attorney explaining why pasting CUI into a public chatbot was fine, ISOO Notice 2026-01 is the document sitting on the other side of the table. Treat it as the clearest available statement of the standard, even though it is not the clause that binds you.

The same government that wrote that notice launched GenAI.mil in December 2025, running Google’s Gemini certified for CUI at Impact Level 5, for about three million users. That is not a contradiction. It is the whole lesson in one sentence: the model is not the problem, the boundary is.

What the vendors actually do with your text

Most people who tell me “we’re fine, we turned off training” have not read the terms. Every major vendor draws the same line in the same place, and it is not where you think.

Vendor	Consumer / personal account	Business or enterprise tier
OpenAI	Content may be used to improve models depending on settings; deleted chats purged within 30 days	Content not used for training by default across API, ChatGPT Business, ChatGPT Enterprise
Anthropic	Free/Pro/Max: if you allowed training, five-year retention; if you declined, 30 days	Claude for Work, Claude for Government, Education and API use are excluded from that change entirely
Google Gemini	18-month default activity retention; a subset of chats reviewed by humans and kept up to three years	Workspace tiers governed by the Workspace terms, not the consumer Gemini Apps terms
Microsoft Copilot	Personal account: training on by default, 18-month conversation retention	Microsoft 365 Copilot: prompts, responses and Graph data not used to train foundation models

Google’s consumer disclosure is the one I read out loud to clients, because it is the most explicit and the most uncomfortable:

“Please don’t enter confidential information that you wouldn’t want a reviewer to see or Google to use to improve our services.”

And note the trap buried in that policy: turning off your activity history does not shorten the three-year retention on chats that were already sampled for human review. The delete button does not reach backwards.

Now hold that next to the definition of compromise in your own 7012 clause: “disclosure of information to unauthorized persons… in which unauthorized intentional or unintentional disclosure… or the copying of information to unauthorized media may have occurred.”

Unintentional. Copying to unauthorized media. That language was written long before chatbots existed and it fits an employee paste like it was drafted for one.

Your people are already doing this

I would rather cite measured behavior than a survey where people self-report how careful they are. The LayerX 2025 report is built on browser telemetry — what users actually did, not what they said they did:

• 77% of users paste data into generative AI tools.
• 82% of that pasting comes from unmanaged accounts — personal logins your admin console cannot see.
• 22% paste content containing PII or payment data; 40% of files uploaded to AI tools contain it.
• Employees average roughly four sensitive pastes per day through unmanaged accounts.

IBM’s 2025 Cost of a Data Breach study adds the governance side: 63% of organizations have no AI governance policy at all, and 97% of breached organizations that had an AI-related incident lacked proper AI access controls.

If you are a twelve-person shop and you have not made a decision about this, you have not avoided the risk. You have delegated it to whoever on your team is most impatient.

The 72-hour question nobody has answered

Here is where I have to tell you something uncomfortable rather than something clean.

DFARS 7012(c) requires you to “rapidly report” — within 72 hours of discovery — any cyber incident, and defines a cyber incident as actions taken through computer networks resulting in a compromise or an actual or potentially adverse effect on a system or the information in it. Reporting goes to dibnet.dod.mil.

I could not find any published DoD guidance holding that an employee pasting CUI into an unapproved chatbot is a reportable cyber incident. Not a memo, not an FAQ, not a DIBCAC position. The question is genuinely unresolved.

What I can tell you is how the argument runs. The clause’s definition of compromise covers unintentional disclosure and copying to unauthorized media. A browser posting text to a vendor’s API is plainly an action taken through a computer network. Put those together and the paste fits the definition on its face. The counter-argument — that this is an internal policy violation rather than a network security incident — is one I have heard from competent people, and I have not found a single piece of published DoD guidance supporting it.

My advice, and it is advice rather than a citation: decide this in advance, in writing, with your counsel. Write down the criteria you will use, before it happens. The worst possible time to develop a position on whether something is reportable is on hour 60 of a 72-hour clock.

Separately, DoDI 5200.48 requires reporting misuse, mishandling, or unauthorized disclosure of CUI through your unauthorized disclosure program. That obligation is not the same thing as the 7012 clock and does not go away just because you conclude the 7012 clock did not start.

If your CUI is also export controlled, the analysis gets worse

A great deal of the CUI in the defense industrial base is also ITAR technical data. If that describes your drawings, your specs, or your test results, there is a second regime stacked on top and it is less forgiving.

People reach for the encryption carve-out at 22 CFR 120.54(a)(5) — the rule that says sending or storing technical data is not an export if it is unclassified, secured with end-to-end encryption, uses FIPS 140-2-compliant modules, and does not touch a proscribed country. That carve-out is why you can put ITAR data in a properly configured cloud file share.

It does not reach AI inference, and the reason is in the definition. Section 120.54(b)(1) defines end-to-end encryption to require that “the means of decryption are not provided to any third party.”

A cloud AI service has to decrypt your prompt in order to answer it. The model cannot run on ciphertext. The provider necessarily holds the means of decryption, which means the carve-out cannot apply. You are back to the ordinary analysis: releasing technical data to a foreign person — including a foreign-national employee of the vendor, or infrastructure located abroad — is a deemed export requiring authorization.

To be straight with you: I found no DDTC advisory opinion or enforcement case addressing AI vendors specifically. That is my reading of the regulatory text, not the State Department’s published position. But it is a clean reading, and I would not want to be the one arguing the other side of it.

One flat statutory ban most contractors have never heard of

Section 1532 of the FY2026 NDAA, signed in December 2025, says this:

“No contractor may, during the period of performance of such contractor under a contract with the Department of Defense, use covered artificial intelligence.”

“Covered artificial intelligence” is defined to include AI developed by DeepSeek and by High Flyer and affiliated entities, and the surrounding definition of covered AI companies reaches entities on the Consolidated Screening List, on the civil-military fusion list, or domiciled in China, Russia, Iran, or North Korea.

Notice what this provision is not about. It is not about CUI. It is not about cloud. It is not about FedRAMP. It is a prohibition on use, during period of performance, full stop. It applies to a contractor with no CUI whatsoever. And because it bans use rather than transmission, downloading the open weights and running them on a laptop in your own building does not cure it.

If anyone on your team has been experimenting with Chinese-origin open models, that is a conversation to have this week, not next quarter.

What this does to your subs — and to you as somebody’s sub

DFARS 7012(m) requires you to flow the clause down “without alteration, except to identify the parties,” into subcontracts involving covered defense information. Subcontractors have to give you their incident report number promptly after reporting to DoD.

Read (b)(2)(ii)(D) again with that in mind. Your obligation is to “require and ensure” that any external cloud service provider meets the standard. That is an affirmative duty on you. A prime that has never once asked its subcontractors what AI tools they use has a thin story about how it required and ensured anything.

I have to flag the limit of what I can tell you: I found no case, settlement, or DoD guidance allocating liability for a subcontractor’s AI-related spill. This is exposure created by clause language, not doctrine established by a decided case. But if you are a prime, add one line to your subcontractor questionnaire — list every AI service used in performance of this contract — and you have converted an unknown into a documented one for almost no cost.

Nobody has been prosecuted for this yet. That is not comfort.

I looked hard for an enforcement action involving AI and CUI. As of the end of August 2026 there is not one. No DoJ case, no False Claims Act settlement, no published DIBCAC finding. I would rather tell you that plainly than imply a peril that has not materialized.

What exists instead is the shape of how one would arrive. On June 18, 2026, LOGZONE, Inc. of Huntsville, Alabama agreed to pay $507,144 to resolve False Claims Act liability for failing to implement NIST SP 800-171 controls on two Navy contracts between May 2021 and March 2025. A DIBCAC assessment scored the company at -170, which DoJ described as the low end of a possible range running from -203 to 110.

Two details make that case the right analogy. First, it was government-initiated — not a whistleblower case. DoJ appears to be working directly from assessment results. Second, the theory was not “you used a forbidden technology.” It was the gap between the security posture the company asserted and the environment as it actually existed.

An unapproved AI tool sitting in your environment is exactly that kind of gap. It is not in your asset inventory. It is not in your system security plan. It is not on your network diagram. And you signed an annual affirmation saying your controls were implemented. That is how AI reaches False Claims Act liability without any AI-specific rule ever being written.

Three things to do this week

None of this requires a budget cycle.

1. Find out what is already in use. Not a survey — check your egress logs or your browser management for traffic to the major AI domains. You will find more than you expect, and most of it will be personal accounts. You cannot write a policy about a problem you have not measured.
2. Give people a sanctioned option. Every prohibition without an alternative gets routed around. If your staff have an approved tool inside your boundary for the work that can use one, and a clear line for what can never leave, compliance stops depending on willpower. A ban with no sanctioned path is a policy that generates violations.
3. Write down the incident criteria before you need them. One page: what counts as a suspected CUI spill into an AI tool, who gets called, who decides whether the 72-hour clock has started, and how you preserve the evidence. Get counsel’s eyes on it once. It will cost you an afternoon and it is the difference between a controlled response and a panic.

The contractors who get hurt by AI over the next two years will not be the ones who used it. They will be the ones who never decided, never documented, and then affirmed compliance anyway.

---

Where to go next

• Not sure where you stand? Take the CMMC readiness quiz — it takes about five minutes.
• Start with the fundamentals in our CMMC guide for small contractors.
• Need the documentation itself? Our CMMC packets give you the SSP, policies and procedures to build from.