CMMC | AI | GovCon | September 2026
By David Dillow, CTO, Greypike Inc.

Most defense contractors have figured out what not to type into an AI tool. Almost none have figured out what to do with AI-generated CUI, the summaries, tables, and analyses that come back out.

Back in June, I wrote about where your data goes when you paste information into an AI chat window. That conversation was about inputs. Somebody drops CUI into a chatbot, and suddenly that information is moving through infrastructure they don’t control.

Since then, I’ve had essentially the same follow-up conversation at multiple industry events.

It usually goes something like this:

“Okay, we got it. We locked down the tools. Nobody’s pasting CUI into ChatGPT anymore. We’re good.”

And then I ask the next question.

“What about what the AI gives back?”

That’s usually where the room gets quiet.

Because the next AI compliance challenge isn’t what goes into the model.

It’s what comes back out.

If there’s one question every contractor should start asking now, it’s this:

What happens to AI-generated output after it’s created?

Most organizations have spent the last year focused on preventing employees from entering sensitive information into unauthorized AI platforms. Very few have established rules for the summaries, tables, reports, and recommendations those platforms generate.

That’s where I think the next wave of findings will come from.

Because if you process Controlled Unclassified Information inside an approved AI environment, the resulting output doesn’t magically become unclassified.

The summary isn’t a new document.

The table isn’t a fresh dataset.

The analysis isn’t disconnected from the information it was built from.

In most cases, it’s still derived from CUI and carries the same protection obligations.

CUI goes in. CUI comes out.

Most contractors are treating the output like it’s clean.

It isn’t.

The Real Risk Nobody Is Talking About

The challenge with AI-generated CUI is that it doesn’t arrive looking like CUI.

Normally, protected information is easy to recognize. Technical data packages arrive with markings. Controlled documents live in protected repositories. Files carry banners, labels, and handling instructions. People generally know the drill.

AI changes that.

An engineer drops a marked technical specification into an approved assistant operating entirely inside the company’s authorized environment. That’s exactly what the tool is there for. She asks it to pull out the five key requirements in plain language, and ten seconds later she has a clean, readable paragraph sitting in a chat window.

What is that paragraph?

It’s not the original document. It has no banner marking, no portion marking, and no cover sheet. It feels more like personal notes than controlled information.

So she copies it into an email. Or a Teams chat. Or a Word document. Or a slide deck for a program review.

And the CUI just walked out the door.

Nobody did anything malicious. Nobody bypassed a control. The approved environment worked exactly as designed.

The problem is that nobody stopped to decide what the output actually was.

The gap wasn’t the AI tool.

The gap was governance.

What Derived CUI Actually Looks Like

In practice, I see this show up in three common forms.

Summaries. A forty-page statement of work becomes a one-page executive summary. It’s shorter and easier to read, but the underlying sensitive information is still there. In some cases it becomes more concentrated than it was in the original document.

Extractions. “Pull every deliverable date, milestone, and part number into a table.” Now you’ve condensed hundreds of pages into a portable list containing exactly the data someone would want.

Analysis. “What are the biggest risks in this program schedule?” The AI’s answer may reveal more about the schedule than the schedule itself. A well-written risk assessment often exposes priorities, dependencies, and program realities that weren’t obvious in the source material.

None of these examples arrive marked as CUI.

Many of them still require protection.

There is no detailed DoD rulebook today that explains exactly how every AI-generated derivative should be marked and handled. The guidance hasn’t fully caught up with the technology.

But the absence of detailed guidance has never relieved a contractor of the obligation to protect controlled information.

That’s not how CUI works.

And it’s certainly not how the Department of Justice reads contracts.

Congress Already Started Building the Next Compliance Framework

Here’s the part that isn’t getting enough attention.

Congress has already directed the Department of Defense to build an artificial intelligence security framework and integrate it into both the DFARS and the CMMC program.

That should matter to every contractor paying attention to AI.

Because AI governance is no longer just a best practice discussion.

It’s becoming an acquisition requirement.

The framework itself is still being developed, but the direction is clear. Contractors that develop, deploy, host, store, or support AI capabilities for the Department of Defense should expect formal security requirements, oversight obligations, monitoring expectations, and compliance evidence requirements.

The driver behind all of this is Section 1513 of the FY2026 National Defense Authorization Act, signed into law in December 2025 under the title:

“Physical and Cybersecurity Procurement Requirements for Artificial Intelligence Systems.”

Here’s what contractors need to know.

Section 1513 directs the Department of Defense to create a risk-based AI security framework built on existing standards such as the NIST 800-series publications. It specifically calls out issues including insider threats, supply chain risk, adversarial manipulation, workforce risk, and security monitoring.

More importantly, Congress didn’t position AI governance as an optional best practice. It instructed DoD to incorporate that framework into acquisition requirements through both DFARS and CMMC.

For anyone who has lived through the evolution of cybersecurity requirements over the last decade, that path should feel familiar.

A framework.

Written into acquisition regulations.

Required through contracts.

Some people have started calling it “CMMC for AI.”

That’s probably not far off.

The legislation also defines covered AI technologies broadly. We’re not just talking about chatbots. The scope reaches source code, training data, algorithms, model weights, and supporting infrastructure.

In other words, the whole stack.

The direction of travel isn’t subtle.

“But CMMC Phase 2 Is Suspended. Doesn’t That Buy Me Time?”

I hear this one constantly.

The suspension changed a schedule.

It did not change DFARS 252.204-7012.

It did not remove NIST SP 800-171 requirements.

It did not eliminate SPRS scoring obligations or annual affirmations.

And it certainly did not repeal a law passed by Congress.

Section 1513 is operating on a different track.

Different requirement.

Still moving forward.

Six Questions Every Contractor Should Be Asking Right Now

The good news is that none of this requires some exotic new technology purchase.

What it requires is governance.

The same governance muscle CMMC already forced most organizations to build.

If an assessor walked in tomorrow and started asking questions about AI usage, these are the questions I’d expect first.

1. Which AI tools are approved?

You need an inventory.

Then you need to find everything that isn’t on the inventory.

Because it’s almost certainly there.

Browser extensions, meeting transcription tools, note-taking applications, and embedded AI assistants are showing up across organizations faster than most security teams realize.

That’s shadow AI.

Most organizations don’t have an AI problem.

They have a visibility problem.

2. What information is allowed in each tool?

Not a guideline.

A written rule.

FCI here.

CUI there.

ITAR nowhere near this one.

Every category should have clear handling guidance.

3. What happens to the output?

This is the big one.

Your policy should clearly state that output derived from CUI is treated as CUI until a qualified human reviews it and determines otherwise.

Ask yourself:

• Where is it stored?
• How is it marked?
• Who reviews it?
• Can it be emailed?
• Can it be inserted into a slide deck?
• Can it leave the enclave?
• What audit trail exists?

If you don’t have answers to those questions, your AI policy isn’t finished.

4. Who used what, when, and with which data?

Logging should include not only tool access, but prompt and output activity retained as auditable records.

When something eventually goes wrong, “we don’t think anybody did that” is not evidence.

Logs are evidence.

5. Does the model train on your data?

Get the answer in writing.

Not from a marketing page.

Not from a sales presentation.

From the contract.

6. What are your subcontractors doing?

The same way cybersecurity requirements flow through the supply chain, AI governance eventually will too.

Your suppliers’ AI practices will become your problem faster than most organizations expect.

If you can answer all six questions with documentation instead of opinions, you’re already ahead of most of the Defense Industrial Base.

The Bottom Line

For the last two years, most conversations about AI in the Defense Industrial Base have focused on information leaving the environment. Contractors worried about employees pasting sensitive information into consumer AI platforms and losing control of where that information ended up.

That’s still a concern, but I increasingly think it’s yesterday’s problem.

The issue I see emerging now is what happens after an approved AI system produces something useful. A summary of a technical data package. A table extracted from a statement of work. An analysis of a program schedule. Those outputs often contain the same sensitive substance as the original material, yet they arrive without the markings and handling cues people normally associate with CUI.

That’s the blind spot.

Congress has already directed the Department of Defense to build an AI security framework and integrate it into acquisition requirements. Whether that framework arrives next year or several years from now is almost beside the point.

The direction has already been set.

The organizations that start governing AI-generated output today will be in a much stronger position than the organizations still debating whether AI belongs in the workplace at all.

At this point, the question isn’t whether your employees are using AI.

They are.

The question is whether you can demonstrate that the information coming back out of those systems is being protected as carefully as the information that went in.

Because sooner or later, somebody is going to ask.

And “we never thought about the output” won’t be the answer they’re looking for.

Frequently Asked Questions

Is AI-generated output from CUI also CUI?

In most cases, yes. Information derived from CUI, whether that’s a summary, an extraction, a table, or an analysis, generally carries the same protection obligations as the source material, even though the output arrives with no markings on it. Treat it as CUI until a qualified human reviews it and determines otherwise.

Can AI summarize CUI?

Only inside an environment authorized to handle CUI, and only if you treat the summary as CUI as well. An approved tool operating inside your boundary does not make the output unprotected. The tool being compliant and the output being governed are two separate questions.

What is NDAA Section 1513?

It is a provision of the FY2026 National Defense Authorization Act, signed into law in December 2025, titled “Physical and Cybersecurity Procurement Requirements for Artificial Intelligence Systems.” It directs the Department of Defense to build a risk-based AI security framework and incorporate it into acquisition requirements through both the DFARS and the CMMC program.

Does the CMMC Phase 2 suspension delay Section 1513?

No. The suspension changed a CMMC implementation schedule. Section 1513 is a separate statutory requirement passed by Congress, and it is unaffected by that pause. Neither are DFARS 252.204-7012, NIST SP 800-171, or your SPRS scoring and annual affirmation obligations.

Is there an official DoD rule today for marking AI-generated CUI?

Not a detailed published one. The guidance hasn’t fully caught up with the technology. But the absence of specific instructions does not remove your existing obligation to protect controlled information in any form, including derived form. Write the policy now.

What is shadow AI, and why does it matter for CMMC?

Shadow AI is undocumented employee use of AI tools on company systems. Browser extensions, meeting transcription tools, note-taking applications, and embedded assistants. It matters because information can flow into unauthorized tools with no record of what happened, and no record is exactly what an assessor cannot accept.

Where should a contractor start?

Inventory the AI actually running in your environment, then write a short rule covering which tools are approved, what information is allowed in each one, and what happens to the output. That single document answers most of what’s coming.

A Note on Doing This Safely

At Greypike, compliance is the problem we build for. We help defense contractors deploy private, CUI-safe AI inside FedRAMP-authorized and GCC High environments, so sensitive information never leaves a boundary you control. Our AI GRC module governs the AI your business already runs against NIST AI RMF and ISO/IEC 42001, which means the inventory, the policies, and the logs are already in place when the Section 1513 framework lands in the DFARS.

Greypike Inc. is a veteran-owned firm specializing in CMMC compliance, secure cloud enclaves, and CUI-safe AI for the Defense Industrial Base.

Want to talk through what safe AI looks like in your environment? Book a free scoping session with us.