Insights · AI Governance
Can you put CUI into generative AI?
The honest answer is that it depends on five things, and none of them is the vendor's marketing page. A decision framework for security leaders who have to sign off.
The previous brief argued that classifying an AI vendor as an ESP or an SPA follows the data flow rather than the product category. This one takes the next step. Once you know what the service is, you still have to decide whether controlled information can go into it.
That decision gets asked of security leaders in a form that cannot be answered: "Can we use ChatGPT?" or "Is Copilot approved for CUI?" Both questions treat a product name as if it were an architecture. It isn't. The same brand can offer a consumer tier, a commercial enterprise tier, and a government cloud tier with entirely different boundaries, retention behaviour and contractual terms.
What follows is the framework I use. Five gates, in order. A service has to clear all five. In practice, the difficult questions usually appear once we reach the provider evidence and technical enforcement gates.
Three requirements people collapse into one
- CMMC determines the assessment requirements and scope under 32 CFR Part 170. CMMC Level 2 currently uses NIST SP 800-171 Rev. 2 as its assessment baseline.
- DFARS 252.204-7012 creates the contractual safeguarding and reporting obligations, and contains the FedRAMP Moderate equivalency requirement for external cloud service providers handling covered defense information.
- NIST SP 800-171 supplies the security requirements for protecting CUI in nonfederal systems. Rev. 3 is NIST's current publication, but it is not currently the CMMC Level 2 assessment baseline.
Keeping those three separate matters here more than usual, because the answer to "can this hold CUI" often comes from the contract rather than from the assessment framework.
Framing
The question underneath the question
When someone asks whether CUI can go into a generative AI service, they are usually asking one of three different things and have not separated them.
| What they say | What they mean | Who answers it |
|---|---|---|
| "Is this tool approved?" | Has someone already made this decision so I don't have to? | Your approved-services list, if you have one |
| "Is the vendor compliant?" | Can I transfer the obligation to them? | Nobody — the obligation stays with you |
| "Can we put CUI in it?" | Does our architecture and contract permit this data flow? | Security, with contracts and IT |
Only the third is a real question, and it is the one this brief answers. The first is a process gap. The second is a misunderstanding worth correcting early, because it shapes every conversation that follows.
Gate one
Is it actually CUI?
Start here, because a surprising share of AI approval requests collapse at this step. Not everything on a defense program is controlled, and treating all of it as CUI produces a blanket prohibition that people route around rather than follow.
The determination follows your contract and the markings on the material, not intuition about sensitivity. A proposal narrative, an internal cost model and an engineering drawing may all feel sensitive while only one is CUI. Derived material matters too: a summary of a controlled document generally carries the same protection as the source, which is exactly what makes AI summarization a scoping problem rather than a productivity feature.
Practical effect. If the material is not CUI and is not covered defense information, most of this framework does not apply, and you are making an ordinary commercial risk decision about confidentiality and intellectual property. Say so plainly — it is the fastest way to make the controlled cases credible.
Gate two
Does CUI actually enter the service?
This is the gate people skip, and it is where architecture starts to matter more than product tier.
"Using an AI tool" describes several different data flows. A model running entirely on a workstation inside your boundary is one thing. A hosted service that receives a prompt and returns a completion is another. A retrieval augmented system that indexes your document repository and passes chunks of it into a prompt at query time is a third — and that one can be built almost anywhere on the spectrum, with the index inside your boundary and inference outside it, or both external, or both internal.
| Deployment | Does CUI leave your boundary? | What decides it |
|---|---|---|
| Model hosted on your infrastructure | No, if inference is fully local | Telemetry, update channels, and any cloud callback |
| Hosted API or web interface | Yes, whenever a user includes it | Prompt content, uploads, and connected data sources |
| Retrieval augmented (RAG) | Depends on architecture | Where embeddings, indexes, retrieval and inference each occur |
| Agent with system connectors | Potentially | What the agent can retrieve, where processing occurs, and what its identity is authorized to access |
The agent row deserves its own treatment and gets it in a later brief. For now, note the difference: a chatbot receives what a person deliberately types, while an agent retrieves what its permissions allow. Those are different risk models even when the underlying model is identical.
Gate three
What does the DFARS clause require?
If CUI or covered defense information enters an external service, the contractual analysis begins. Under DFARS 252.204-7012, covered contractor information systems are subject to NIST SP 800-171. And where a contractor intends to use an external cloud service provider to store, process, or transmit covered defense information, paragraph (b)(2)(ii)(D) requires the contractor to require and ensure that the provider meets security requirements equivalent to the FedRAMP Moderate baseline, and complies with the clause's cyber incident reporting, malicious software, media preservation, and damage assessment provisions.
Two words in that sentence carry most of the weight: equivalent and ensure.
What equivalency means in practice
DoD CIO guidance tightened what contractors may accept as equivalency. A vendor's own assertion does not satisfy it. The expectation is full compliance with the current FedRAMP Moderate baseline, assessed by a FedRAMP-recognized third-party assessment organization, producing a prescribed body of evidence — system security plan, assessment plan, assessment report and plan of action. A marketing claim or a general security certification is not a substitute.
DoD's CMMC FAQ has since confirmed the same position in CMMC terms: a cloud service provider processing CUI must be FedRAMP Moderate authorized or meet the equivalency requirements. That is worth knowing about, because it closes the argument that the equivalency memo was a DFARS matter sitting outside the CMMC assessment.
| Vendor status | What it gives you | What you still owe |
|---|---|---|
| FedRAMP Moderate authorized, service in boundary | The cleanest position available | Confirm the specific service is named in the authorization |
| Claimed equivalency | Depends entirely on the evidence behind it | Obtain and review the body of evidence; document your acceptance |
| SOC 2 or ISO 27001 only | General assurance, not the clause requirement | Treat as insufficient on its own for covered defense information |
| Nothing beyond a security webpage | Nothing | The service does not hold CUI |
The boundary trap. A provider being authorized does not mean the service you want is authorized. Newer offerings — generative AI features in particular — frequently sit outside the boundary for a period after launch. Check the service by name against the authorization package rather than relying on the provider's overall status.
Gate four
Can you enforce it technically?
Suppose the first three gates clear and you have a service that may hold CUI. You now have the opposite problem: everything else people use must not receive it, and telling them so is not a control.
NIST SP 800-171 Rev. 3 requirement 03.01.20 addresses the use of external systems and the conditions that have to be satisfied before authorized individuals use them to process, store, or transmit CUI. Satisfying a condition means something more than publishing it.
A note on revisions. Rev. 3 is NIST's current publication and its treatment of external systems and external system services is the clearest articulation available. CMMC Level 2 remains tied to Rev. 2 under 32 CFR Part 170. I cite Rev. 3 here as useful current NIST guidance on the principle, not as a statement that the CMMC Level 2 assessment baseline has moved.
The enforcement layer usually looks like some combination of network controls that block unapproved services from systems that hold CUI, browser or endpoint policy that prevents paste and upload into those destinations, data loss prevention rules tuned for the ways controlled material actually moves, identity controls that keep enterprise accounts from authenticating into consumer tiers, and configuration on the approved service itself — retention settings, connector scope, administrative restrictions on what users can attach.
None of that is exotic. What makes it hard is that AI access is trivially easy to obtain personally, so the failure mode is a personal account on a personal device, and your controls have to account for that path rather than pretending it does not exist.
Gate five
Can you evidence it?
An assessor will not accept a description of your intent. The question is what you can produce.
The evidence set for an approved AI service
- The determination. Written record of what data the service may receive, the classification decision behind it, and who approved it.
- The architecture. A data flow showing where prompts, uploads, indexes and outputs live, and where the boundary sits.
- The contract. The clause flowdown, the retention and subprocessor terms, and the incident reporting obligations you can actually invoke.
- The provider evidence. Authorization documentation or the equivalency body of evidence, with the specific service named.
- The enforcement. Configuration exports and policy screenshots showing the restrictions are live, not just written.
- The monitoring. Logs demonstrating you would detect use of an unapproved service, and what happens when you do.
If you cannot assemble items four, five and six, the honest position is that the service is permitted for non-controlled work only. That is a defensible answer. "We have a policy against it" is not.
Alternatives
When the answer is no
A prohibition with no alternative will eventually be worked around, and that is worse than the risk you were managing. If a service cannot hold CUI, give people a route that works.
| Approach | Where it fits | What it costs |
|---|---|---|
| Government cloud tier | Where the provider offers one covering the service you need | Price, feature lag behind commercial |
| Self-hosted model inside the boundary | Summarization, drafting, code assistance on controlled material | Infrastructure, model quality, ongoing operation |
| Approved commercial tool, non-CUI work only | The large share of daily work that is not controlled | Requires people to classify correctly, every time |
| Redaction or synthetic substitution | Narrow, structured tasks | Fragile; re-identification risk is real |
The third row carries more weight than it looks like. Most work in a defense contractor is not controlled. An approved tool for that majority, with a clear line and enforcement at the line, removes most of the pressure that drives people to shadow accounts.
References
Primary sources for this brief
- DFARS 252.204-7012 — safeguarding covered defense information and cyber incident reporting, including paragraph (b)(2)(ii)(D)
- DoD CIO memorandum on FedRAMP Moderate equivalency for cloud service providers
- DoD CMMC FAQ — cloud service provider requirements for CUI
- 32 CFR Part 170 — CMMC Program definitions and scoping; NIST SP 800-171 Rev. 2 as the Level 2 baseline
- NIST SP 800-171 Rev. 3 — 03.01.20 (external systems) and 03.16.03 (external system services), cited as current NIST guidance
- FedRAMP authorization boundary guidance
FAQ
Common questions
Can we put CUI into ChatGPT?
I would not answer that at the brand level. Consumer ChatGPT, commercial enterprise offerings, FedRAMP-authorized offerings and API deployments do not necessarily share an authorization boundary. Identify the exact service and deployment first, then assess the contractual requirement, the authorization boundary and the permitted data types. FedRAMP Moderate status matters, and it is not a substitute for the workload-specific determination.
Does an enterprise agreement make a service compliant?
No. An enterprise agreement usually improves retention terms and administrative control, both of which matter. It does not by itself satisfy the DFARS requirement for cloud services handling covered defense information.
The vendor says they don't train on our data. Is that enough?
No, and it is the most common misconception in this area. Training is one data use among several — processing, transient storage, logging, retention and subprocessor access are separate questions, and a service can do all of them without training on anything. A later brief in this series takes that claim apart in full.
What if the AI is running on our own servers?
Then the model is a system component inside your boundary and gets treated like any other: inventory it, control access to it, log it, and include it in your assessment scope. Confirm there is no telemetry or update channel quietly sending data outward.
Is summarizing a CUI document with AI different from uploading it?
If an external service performs the summarization, the source content has to be processed by that service — so the inbound flow is the same problem either way. The resulting summary then has to be evaluated for CUI in its own right. Summarization does not automatically decontrol the underlying information, and it does not automatically make the output controlled either.
Who should own this decision?
The business or program owner establishes what information is actually being handled. Contracts establishes the contractual requirements. Security determines whether the proposed architecture can satisfy them. IT implements the controls. Where those functions are not working together, AI approval becomes an informal product decision rather than a controlled data decision.
Need a defensible answer on a specific AI service?
We run the five gates against the tool you're evaluating — classification, architecture, contract, enforcement and evidence — and give you a written determination your assessor can read.
Book a scope call. Thirty minutes, no charge.
This series
- 01 · Are AI vendors ESPs or SPAs under CMMC?
- 02 · Can you put CUI into generative AI? (you are here)
- 03 · The CMMC AI vendor questionnaire — forthcoming
- 04 · AI agents change the CMMC boundary — forthcoming
- 05 · "We don't train on your data" is not enough — forthcoming
Related briefs
This brief reflects published guidance as of 6 September 2026. CMMC Level 2 is assessed against NIST SP 800-171 Rev. 2; references to Rev. 3 are to NIST's current publication and not to the assessment baseline. Cloud service authorization status, provider tiers and equivalency expectations change frequently — verify the current DFARS text, DoD guidance and your provider's authorization package before relying on them. Advisory content, not legal advice.
Cyber DSC · Insights · AI Governance Brief 02 · 06 Sep 2026