Can You Use AI in a CUI Environment?

The short answer

Yes. A defense contractor can use AI in an environment that handles Controlled Unclassified Information, under conditions that are already written down.

Nobody has to guess at the conditions, because they do not come from an AI regulation. They come from a chain that already binds every covered contract: a contract clause, then a program rule, then evidence you hold. This page walks the chain with the primary sources.

Where does the obligation actually come from?

The chain starts in the contract. DFARS 252.204-7012(b)(2)(ii)(D) states:

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 and that the cloud service provider complies with requirements in paragraphs (c) through (g) of this clause for cyber incident reporting, malicious software, media preservation and protection, access to additional information and equipment necessary for forensic analysis, and cyber incident damage assessment.

Read the whole sentence. The half that gets dropped in vendor marketing is the second half: equivalence to the FedRAMP Moderate baseline is not the whole test, because the clause also requires the provider to accept the incident reporting, malware, media preservation, forensic access, and damage assessment obligations.

A hosted AI service that stores, processes, or transmits CUI is an external cloud service provider under that clause. The obligation attaches to the information, not to whether the tool is marketed as productivity software.

Is the AI service a CSP or not?

The program rule then decides how the service is treated in a CMMC Level 2 assessment. 32 CFR 170.19(c)(2) resolves it on one question: is the external service provider also a cloud service provider?

That fork produces exactly two routes to approving an AI service for CUI. Route A: the service is a CSP, and you hold the FedRAMP Moderate authorization record or the equivalency body of evidence, plus the provider's agreement to paragraphs (c) through (g). Route B: the service is not a CSP, it is documented in your System Security Plan, and it is assessed inside your scope, which is realistic only for self-hosted or dedicated-tenancy deployments under your control.

Why is "equivalent" stricter than "authorized"?

It sounds backwards, and on one axis it is true. A FedRAMP authorization tolerates open plan-of-action items. The equivalency path does not: the DoD CIO body of evidence for equivalency requires a System Security Plan, a Security Assessment Plan, a Security Assessment Report from a FedRAMP-recognized 3PAO, and a plan of action and milestones for continuous monitoring only, with no open POA&M items at validation.

The verification burden sits with you, not the vendor. A provider asserting equivalency is not evidence; the body of evidence in your possession is. A vendor statement that it does not train on your data is a retention commitment, not a FedRAMP determination, and it approves nothing by itself.

What does CMMC actually say about AI today?

Nothing. Six primary documents were checked and agree: NIST SP 800-171 Rev. 2, 32 CFR Part 170, DFARS 252.204-7012, the CMMC Scoping Guide Level 2 v2.13, the CMMC Assessment Guide Level 2 v2.13, and the DoD CMMC FAQ contain no reference to artificial intelligence, machine learning, or large language models.

That is not a gap that excuses anything. It means AI is governed by the existing requirements, applied to a new kind of external system. An assessor does not need an AI control to find that CUI left the boundary without authorization. The requirements that actually attach are 3.1.3 (CUI flow across a boundary), 3.1.20 (connections to external systems), 3.4.8 and 3.4.9 (software execution controls on the endpoint), and the 3.13 family for boundary protection and protection of CUI in transit and at rest.

NIST's AI frameworks, AI 100-1 and the Generative AI Profile AI 600-1, are voluntary. Neither is incorporated into 32 CFR Part 170 or DFARS. Adopting them can be a defensible governance choice; it is not a CMMC requirement and will not be assessed by a C3PAO. As for what is coming: Public Law 119-60 section 1513, titled "Physical and cybersecurity procurement requirements for artificial intelligence systems," is real, and what its framework will require is not yet settled, so this page does not state it as settled.

What about the Mac in front of you?

On a managed Mac fleet the more likely AI event is not a user signing up for a chatbot. It is the capability arriving on its own, enabled, in an operating system update. Apple states that Apple Intelligence is turned on automatically after updating to macOS 15.3 or during device setup, unless device management skips the Apple Intelligence setup pane.

Four facts shape what you can actually control. There is no master Apple Intelligence off switch; each surface is denied individually, and a surface with no management key cannot be denied at all. The control mechanism changed at macOS 26.4, where Apple deprecated the restriction keys and replaced them with three declarative configurations that are available under supervised enrollment only. Requests that use Private Cloud Compute leave the device; Apple's public commitments concern retention and access, not non-transmission. And Apple's SOC 3 examination of Private Cloud Compute states that the examinations were not conducted to evaluate the performance or integrity of Apple's artificial intelligence services, and that the independent auditor does not express an opinion or any other form of assurance about those services.

On the approval question the position is plain: no FedRAMP authorization was identified for Apple Intelligence, Private Cloud Compute, or any Apple AI service as of 23 August 2026, and Apple's own internet-services certification page lists ISO/IEC 27001 and 27018 only. That is an absence of positive evidence, stated as such. Absent a Route A body of evidence, features that send requests to Private Cloud Compute are not approvable for CUI, and on-device-only processing is a separate determination made per feature.

What do you actually have to do?

Five things, and all of them are documentation and decision work rather than tooling. Tier your information so every person can tell what may enter which service. Approve services explicitly, with the evidence basis recorded, through Route A or Route B, and treat a capability that arrives in an update as a new, unapproved service. Prohibit the inputs that are never acceptable anywhere: CUI into unapproved services, credentials, configurations, audit logs, export-controlled data. Require human review of AI output before anyone relies on it, because accountability cannot be delegated to a model. And write the spillage path down before you need it, because deleting the conversation is not remediation.

For how this lands in scoping, see which Mac tools are ESPs, CSPs, or neither and does your Mac MDM need FedRAMP authorization. For the blocking-is-not-a-strategy argument, see why blocking AI is the wrong CMMC strategy. For what an AI governance policy needs to contain, see an AI governance policy for defense contractors.