# AI Governance for CMMC Level 2: Can You Use AI Tools in a CUI Environment? > Learn how to decide whether an AI tool can be used in a CUI environment and under what conditions, plus get an AI Policy template that meets CMMC Level 2 requirements. canonical: https://secureframe.com/blog/cmmc-level-2-ai-governance AI tools have moved from novelty to default workflow faster than any enterprise technology in recent memory. For defense contractors, that speed has created a critical question: does using AI tools violate our contractual obligations to protect [controlled unclassified information (CUI)](https://secureframe.com/hub/cui)? No [DFARS clause](https://secureframe.com/blog/dfars), CMMC practice, or NIST requirement mentions generative AI by name, but from a compliance perspective, an AI tool is two things you already have guidance on evaluating: a cloud service and an external system. This article walks through how teams can determine whether an AI tool can be used in an environment that handles CUI, and under what conditions. You’ll also find an AI Policy Template that addresses [CMMC Level 2 requirements](http://secureframe.com/blog/cmmc-level-2-compliance) that you can tailor to your environment. ## What existing regulations require ## What existing regulations require To understand the role of AI tools in an environment that stores, processes, or transmits CUI, start with the regulations and clauses you're likely already familiar with. These are your [existing obligations under DoD contracts](https://secureframe.com/blog/dfars), and each one applies directly to AI tools.  ### DFARS 252.204-7012 sets the bar for cloud services  Paragraph (b)(2)(ii)(D) of the clause states that if a contractor intends to use an external cloud service provider to store, process, or transmit any covered defense information, the contractor "shall require and ensure" that the provider meets security requirements [equivalent to the FedRAMP Moderate baseline](https://secureframe.com/blog/fedramp-equivalency-cmmc). The provider must also comply with the clause's requirements for cyber incident reporting, malicious software, media preservation, forensic access, and damage assessment. Note the trigger: store, process, or transmit. A generative AI service processes every prompt you send it. If CUI can reach the prompt, then the service is subject to this requirement. ### NIST SP 800-171 treats AI tools as external systems Under [NIST 800-171 Rev 2](https://secureframe.com/blog/nist-800-171-rev2-vs-rev3), the standard currently used for [CMMC assessments,](https://secureframe.com/hub/cmmc/assessments) requirement 3.1.20 requires organizations to "verify and control/limit connections to and use of external systems." The discussion text in the publication removes any ambiguity about whether a SaaS AI tool qualifies: external systems explicitly include "accessing cloud services (e.g., infrastructure as a service, platform as a service, or software as a service) from organizational systems," along with personally owned devices.  Requirement 3.1.3 requires controlling the [flow of CUI](https://secureframe.com/hub/cui/asset-mapping) in accordance with approved authorizations, and 3.13.1 requires monitoring and controlling communications at system boundaries.  Under these three requirements, an AI tool is never a simple productivity add-on. It’s either a verified, controlled connection or an unauthorized flow path. ### DFARS 7012 makes unauthorized exposure a reportable event The clause defines a compromise to include "the copying of information to unauthorized media" and requires contractors to rapidly report cyber incidents, defined as within 72 hours of discovery. The clause text still names DIBNet as the reporting portal, but [DIBNet was decommissioned in June 2025](https://isidefense.com/blog/dibnet-portal-shutdown-defense-contractors). Reports now go to the DoD Cyber Crime Center (DC3) through its DCISE reporting process. Say an engineer pastes a note from a controlled drawing into a commercial chatbot to clean up the wording. CUI has been copied to unauthorized media, which meets the clause's definition of a compromise, which makes this a cyber incident affecting covered defense information.  The contractor must review for evidence of compromise, report within 72 hours of discovery, and preserve images of affected systems for at least 90 days in case DoD requests them for a damage assessment. Subcontractors must also pass the incident report number up to their prime. The response consumes weeks of engineering and security time. And if your SPRS score attested to controls the incident shows weren't operating, the gap between your attestation and your environment is now a documented fact, with everything that implies for your score's defensibility. All for one copy/paste made to save ten minutes. ## Recommended reading A Guide to the DFARS Clauses Behind CMMC and How They’ve Changed in 2026 ### The DoD CIO’s memo defines FedRAMP Moderate Equivalency DFARS 7012 gives you the lens for evaluating every external cloud service that touches CUI, and AI tools fall squarely into that category. What the clause doesn't define is what "equivalent to the FedRAMP Moderate baseline" means.  The [DoD CIO's December 2023 memorandum](https://secureframe.com/blog/fedramp-equivalency-cmmc) clarifies that the bar is high. A cloud service offering must achieve 100% compliance with the [FedRAMP Moderate baseline](https://secureframe.com/hub/fedramp/impact-levels) through an assessment by a FedRAMP-recognized 3PAO, with no [Plan of Action & Milestones (POA&M)](https://secureframe.com/blog/plan-of-action-and-milestones-poam) from that assessment. The vendor must also produce a full body of evidence that the contractor is responsible for validating. Very few commercial AI services clear that bar.  ### The FY2026 NDAA makes AI governance an explicit requirement The regulations above apply to AI by interpretation, but Congress has recently made the connection explicit. The [FY2026 National Defense Authorization Act](https://www.congress.gov/bill/119th-congress/senate-bill/1071/text), signed in December 2025, directs the Department of Defense to develop a security framework for AI and machine learning and incorporate it into both the DFARS and the CMMC program (Section 1513). Contractors developing, deploying, storing, or hosting AI for the DoD will be required to meet it. The same law prohibits contractors from using certain foreign-developed AI tools, including DeepSeek and its affiliated entities, in the performance of covered contracts (Section 1532). The framework's requirements haven't been written yet, so there's nothing to implement today beyond the foreign-AI prohibition. But the direction is set: [AI governance](https://secureframe.com/blog/iso-42001) is becoming an explicit contractual obligation rather than an inference from existing clauses. Contractors that build the evaluation discipline below now will be implementing a version of what the coming framework formalizes, ahead of the deadline instead of against it. ## How to know if you can use an AI tool in your environment ## How to know if you can use an AI tool in your environment  Now that you know what bar the AI tool needs to clear, here's a series of logical questions to help you determine if the tool you want to use clears it. ### 1. Could CUI plausibly reach this tool? Not "is it intended to" — could it.  Map the tool's inputs. Prompts and pasted text are the obvious path, but modern AI tools accept far more: file uploads, screenshots, connected drives and mailboxes, meeting audio, browser context, and agent-level access to other applications.  An AI notetaker that joins your program review calls can capture CUI without anyone typing a word. A coding assistant with repository access can ingest controlled technical data the moment a developer opens the wrong project. If the honest answer is that CUI could not plausibly reach the tool because it operates entirely outside your CUI environment and touches only public or non-controlled information, the remaining questions still matter for general security hygiene, but your DFARS obligations are not in play.  ### 2. Where does the data go? Any cloud service that stores, processes, or transmits covered defense information must meet [FedRAMP Moderate equivalency](https://secureframe.com/blog/fedramp-equivalency-cmmc) or hold FedRAMP authorization. For a generative AI service, that means asking: - Does the service hold a FedRAMP authorization, verifiable in the FedRAMP Marketplace?  - If not, can the vendor produce the full body of evidence the DoD CIO memo requires for Moderate equivalency? - Where are prompts and outputs processed and retained, and are they used for model training? Data used for training leaves your control in a way your retention policy can’t address. Authorization status is only half of the due diligence process. The other half is contractual, and it's where AI services likely differ from the cloud tools you've already vetted.  A vendor's public statements about data handling are not evidence you can put in a self-assessment or stand behind in your [System Security Plan (SSP)](https://secureframe.com/blog/cmmc-ssp). You need a data processing agreement or contractually bound instance with explicit terms that cover training-data exclusion, prompt and output retention, and deletion. Negotiate those terms directly or buy through instances that carry them, rather than relying on the standard terms of a consumer or team subscription. If the vendor won't commit those terms to contract, that answer is itself diligence information. Export-controlled information adds a second gate. If your CUI includes [ITAR or EAR technical data](https://secureframe.com/blog/ear-vs-itar), US-person handling requirements apply, and most commercial AI services cannot restrict backend access to US persons regardless of their FedRAMP status. For export-controlled environments, the realistic options narrow to government cloud offerings built for that purpose. ## Recommended reading How to Map and Scope Your CUI Environment ### 3. Is the tool inside or outside your assessment boundary? Every AI tool your organization uses lands in one of three places. Each has different consequences for your SSP and your [SPRS score's defensibility](https://secureframe.com/blog/cmmc-sprs). - **Inside the boundary: **The tool runs within your CUI environment (for example, an AI service deployed in your government cloud tenant). It becomes part of your assessed environment, its controls are your controls, and it appears in your SSP like any other in-scope component. - **Outside the boundary, with a verified connection: **The tool sits outside your CUI environment but connects to it in a controlled, documented way. Requirement 3.1.20 governs here: you verify the external system's controls, establish terms and conditions, and document the connection. - **Outside the boundary, unauthorized: **The tool has no documented relationship to your environment, but CUI can reach it through human behavior. This is where shadow AI lives, and it’s the category that turns an accurate SPRS score into an inaccurate one without anyone touching your SSP. A browser-based chatbot on a work laptop inside your CUI environment is an unverified external system connection. For sanctioned AI tools that process CUI, the scoping treatment is written into the CMMC rule itself. Under 32 CFR 170.19, an external service provider that processes, stores, or transmits CUI and is a cloud service provider must meet the FedRAMP requirements in DFARS 252.204-7012, and its use and the division of responsibilities between you and the provider must be documented in your SSP and the provider's customer responsibility matrix (CRM).  The wrinkle with AI services is that the standard responsibility matrix was not written with them in mind, so prompt logging, output retention, and training data usage don't map to any row in a typical CRM. Document those AI-specific responsibilities explicitly as a supplement rather than assuming the standard matrix covers them. Whoever evaluates your environment next, whether a prime's security review or your own team preparing an annual affirmation, the questions run along the same data path: where a prompt goes, what the model can reach, and where its output is stored. As an example, consider an AI meeting assistant that joins a program review. CUI is discussed on program calls, so it can reach the tool. Where does the transcript processing happen? Does the service meet the bar for CDI, and do its terms address retention and training use? Is this assistant a verified external connection or an unvetted add-on someone enabled for notetaking purposes?  Most commercial meeting assistants will not be authorized for CUI-adjacent meetings, so your AI policy should list approved meeting tools by name. ## Recommended reading An Expert’s Guide to CMMC Level 2 Scoping & Asset Categories ### 4. Can you govern the human layer? The first three questions are architecture. This one is behavior, and it’s where most real-world exposure originates. [NIST 800-171'](http://secureframe.com/blog/nist-800-171-compliance)s discussion of external systems provides the governance mandate: when terms and conditions cannot be established with the owner of an external system, "organizations may impose restrictions on organizational personnel using those external systems." That means three layers: - **Policy:** A written [AI acceptable use policy](https://secureframe.com/compliance-resources/ai-acceptable-use-policy) that names approved tools, prohibited tools, and the categories of information that may never enter an AI system. - **Training:** CUI handling training that addresses AI specifically. Employees who would never email a controlled drawing to a personal account could paste it into a chatbot without registering the difference, because the interaction feels like a search, not a transmission. - **Technical enforcement:** Network and software controls that block unapproved AI services from systems in your CUI environment and log the use of approved ones. One limitation surprises many teams: traditional endpoint DLP is weak against AI tools. Pasting text into a browser-based chatbot looks like ordinary web activity to most DLP configurations, and personal phones bypass network controls.  A layered enforcement approach is more effective: - **Network controls:** Block AI service categories at the firewall or secure web gateway for systems in your CUI environment, the same way most organizations already handle personal cloud storage, with approved services explicitly allowed. - **An AI gateway:** An approach gaining traction in enterprise environments is to route all approved AI traffic through a proxy layer that logs every request, enforces which models and endpoints can be reached, and inspects outbound prompts for controlled data before they leave the network. This gives you a single programmable enforcement and audit point for requirements 3.1.20 and 3.13.1, where policy alone gives you none. ## AI tools for government contractors available today ## AI tools for government contractors available today For many government contractors, the most defensible path to AI tools is through the services already built into government cloud solutions and AI services with a verifiable FedRAMP status.  The major government clouds now include AI services that inherit the compliance posture of the environment they run in: - Azure OpenAI Service runs in Azure Government regions at [FedRAMP High](https://devblogs.microsoft.com/azuregov/azure-openai-fedramp-high-for-government/), giving contractors API access to large language models inside the government cloud boundary, though specific models arrive later than in commercial Azure.  - Microsoft 365 Copilot [reached general availability in GCC High in December 2025](https://techcommunity.microsoft.com/blog/publicsectorblog/microsoft-365-copilot-is-now-available-in-gcc-high/4473310), bringing AI assistance into Word, Outlook, and Teams within the sovereign cloud boundary, with newer features continuing to trail the commercial release.  - Amazon Bedrock runs in AWS GovCloud under FedRAMP High authorization, providing API access to [foundation models from multiple providers](https://aws.amazon.com/about-aws/whats-new/2026/06/GPT54-available-in-aws-govcloud-us-west/).  Because these services operate inside environments already configured for CUI, they are the default starting point for CUI-touching AI use.  ### FedRAMP authorized AI services The [FedRAMP Marketplace](https://marketplace.fedramp.gov/) is the verification source. Search the actual service offering, not the vendor name, because a vendor's commercial product and its government product are separate offerings with separate authorization status. FedRAMP now grants authorizations through two pathways: the traditional Rev 5 baseline process and the newer [FedRAMP 20x](https://secureframe.com/blog/fedramp-20x) pathway, which designates Moderate-level offerings as Class C. FedRAMP treats Class C as the successor to the traditional Moderate baseline, and both pathways produce authorizations listed in the Marketplace. The complication is that DoD's requirements were written before this transition. DFARS 7012 and the CMMC rule reference the FedRAMP Moderate baseline and Moderate equivalency, but neither one says how a 20x Class C certification should be treated. DoD has not yet issued written guidance closing that gap, whether through a class deviation, a DoD CIO memo, or CMMC assessment guidance.  Before moving forward, confirm the offering's Marketplace status and certification profile, confirm the data types in scope, review the customer responsibilities, and record in your evaluation file that the DoD interpretation is unresolved. When your contract names a specific requirement, confirm the acceptable authorization types with your contracting officer. ### Commercial AI tools Commercial AI tools without FedRAMP authorization can still have a place in your organization for workflows that verifiably never touch CUI.  Consider a marketing team using AI to draft public-facing content. Website copy, social posts, and proposal boilerplate built from public information don’t involve CUI, so using commercial AI tools is fine. ## CMMC Level 2 AI acceptable use policy + template ## Building an AI acceptable use policy for your CUI environment Most of your employees are going to use AI tools at some point, and a policy that shows them how to do it safely delivers the productivity benefits while limiting risk exposure. It also forces your organization to [vet AI tools deliberately and strategically](https://www.washingtontechnology.com/opinion/2026/04/ai-and-cmmc-double-edge-sword-defense-contractors/412981/) instead of reacting to requests one tool at a time, which reduces operational, security, and compliance risk before a single control gets configured.  The finished policy is also compliance evidence. It documents how you restrict personnel use of external systems under requirement 3.1.20, and it gives you a concrete artifact when primes, contracting officers, or affirming officials ask how you govern AI. Expect that question more often, not less, now that the FY2026 NDAA has put an AI security framework on the CMMC roadmap. However, a generic AI policy isn't sufficient for a CUI environment. You’ll need to:  - Name approved tools and the data categories permitted for each  - Name prohibited categories, such as meeting assistants and browser extensions  - Include a clear definition of CUI with examples from your own contracts. Employees can't protect what they don't recognize.  - Establish a defined path for reporting when CUI has reached an unauthorized tool so you can meet the 72-hour reporting window - Document how the policy will be enforced - Set a review cadence to keep the approved tool list and reporting processes up to date Our AI Acceptable Use Policy Template is already structured this way and built for CMMC Level 2 requirements, so you can start from a CUI-ready baseline and tailor the policy to your needs. ## AI Acceptable Use Policy Template for NIST 800-171 and CMMC Level 2 Download a customizable AI policy for CUI environments, mapped section-by-section to NIST 800-171 and CMMC Level 2 requirements. ### Can employees use Claude or ChatGPT if our company handles CUI? The commercial versions of these tools do not meet the FedRAMP Moderate bar DFARS 7012 sets for services that store, process, or transmit covered defense information, so they cannot be used where CUI could reach them.  OpenAI announced a FedRAMP 20x Moderate authorization in April 2026 covering its government offering through qualified cloud service providers, but that authorization applies to the government product, not consumer or team ChatGPT. ### Does using AI violate DFARS 252.204-7012? Using AI does not violate the clause. Using a cloud AI service that stores, processes, or transmits covered defense information without FedRAMP Moderate equivalency or authorization does. The evaluation is the same one the clause requires for any cloud service. ### What happens if an employee puts CUI into an unauthorized AI tool? Under DFARS 7012's definitions, copying CUI to unauthorized media is a compromise, which makes the event a reportable cyber incident. The contractor must review for evidence of compromise and report to DoD through DC3 within 72 hours of discovery.