If you’ve been waiting for DoD to publish a dedicated AI chapter in CMMC 2.0, stop waiting. There isn’t one. What exists instead is a set of existing NIST SP 800-171control families that apply directly to any AI system that touches Controlled Unclassified Information (CUI) — and assessors are already asking about them. Understanding the CMMC 2.0 AI requirements for defense contractors means understanding how your AI tools, models, and third-party APIs fit inside the compliance framework you’re already being assessed against.
What CMMC 2.0 Actually Says About AI (And What It Doesn’t)
CMMC 2.0 does not contain a standalone “AI domain.” The framework’s 110 practices map directly to NIST SP 800-171 Rev 2, which was finalized before generative AI entered the enterprise mainstream. DoD has not issued a CMMC-specific AI addendum as of mid-2025.
CMMC 2.0 artificial intelligence controls are not labeled as such. They are buried inside Access Control (AC), Configuration Management (CM), Incident Response (IR), and five other practice families. An AI inference pipeline that processes CUI is subject to the same access, logging, and risk assessment requirements as any other information system in your boundary — because it is an information system in your boundary.
The CMMC AI governance requirements that matter are the ones your C3PAO will evaluate against your System Security Plan (SSP). If your SSP doesn’t describe your AI systems, their data flows, and the controls applied to them, you have a documentation gap before you have a technical one.
Every AI tool that ingests, processes, or outputs CUI must be treated as a system component requiring explicit scoping, boundary documentation, and control mapping — not a productivity application sitting outside the assessment boundary.
The Six CMMC Level 2 Control Families That Govern AI Use
CMMC Level 2 AI compliance in 2026 requires mapping your AI systems to the specific practice families where assessors will look. Six families carry the most direct weight:
1. Access Control (AC) — 22 practices. Who can query your model? Who can access training data repositories? 3.1.1 through 3.1.16 require you to limit system access to authorized users and processes. An AI API endpoint that any employee can hit with a CUI-containing prompt is an AC finding.
2. Configuration Management (CM) — 9 practices. AI models are software components. 3.4.1 requires a baseline configuration for organizational systems. If you’re running a self-hosted LLM or a fine-tuned model, you need a documented baseline, change control, and least-functionality enforcement. Shadow AI deployments — models spun up without IT involvement — are a CM violation waiting to happen.
3. Audit and Accountability (AU) — 9 practices. 3.3.1 requires audit logs that enable individual accountability. For AI systems, this means logging who submitted what to the model, what the model returned, and when. Most off-the-shelf AI tools do not produce CMMC-compliant audit logs by default. You need to verify this explicitly with every vendor.
4. Incident Response (IR) — 3 practices. 3.6.1 requires an operational incident-handling capability. A data exfiltration event through an AI API — intentional or accidental — is a reportable incident. Your IR plan must name AI systems as potential incident vectors and define response procedures specific to them.
5. Risk Assessment (RA) — 3 practices. This is where the CMMC AI risk assessment framework lives. 3.11.1 requires periodic assessments of organizational operations, assets, and individuals. Introducing a new AI tool mid-assessment cycle without a risk assessment artifact is a gap. Every AI system touching CUI needs a documented risk assessment before it goes into production.
6. System and Communications Protection (SC) — 16 practices. 3.13.5 covers cryptographic protections for CUI. 3.13.6 prohibits split tunneling. When CUI flows to a third-party AI API over the public internet, SC controls govern how that transmission is protected. Many contractors assume their AI vendor handles this. The controls require you to verify and document it.
AI Data Protection: Where CUI Meets Your Models and Pipelines
AI data protection under CMMC compliance is the highest-risk gap area for mid-market Defense Industrial Base (DIB) contractors — and the one most likely to produce a finding during a C3PAO assessment.
The problem is architectural. CUI can enter an AI pipeline at multiple points:
- Training data: If you fine-tune a model on internal documents that contain CUI, that CUI is now embedded in model weights. Deleting the source document does not remove it from the model.
- Inference inputs: Every prompt submitted to an AI system is a potential CUI exposure event. Employees paste contract language, technical specs, and program data into AI tools constantly, often without recognizing the CUI category.
- Third-party AI APIs: When your system calls an external AI API — OpenAI, Anthropic, Azure OpenAI, or any other — you are transmitting data to a system outside your authorization boundary. Unless that vendor has a documented data processing agreement that addresses CUI, you have a boundary control failure.
The key question assessors will ask: Does your SSP accurately describe where CUI goes when it enters your AI systems? If the answer is “we’re not sure,” that’s not an honest answer — it’s a finding.
Specific obligations under NIST SP 800-171 that apply here:
- 3.1.3 (AC): Control the flow of CUI in accordance with approved authorizations. An AI API call that routes CUI outside your boundary without documented authorization violates this practice.
- 3.13.10 (SC): Establish and manage cryptographic keys. If your AI pipeline encrypts CUI in transit, you need key management documentation.
- 3.13.16 (SC): Protect the confidentiality of CUI at rest. Model weights trained on CUI are CUI at rest.
AI security for defense contractors who use third-party AI services requires a vendor assessment process — not a checkbox on a procurement form, but a documented technical review of where data goes, how it’s retained, and whether the vendor’s terms permit CUI processing. Get that review in writing before any CUI touches the vendor’s systems.
CMMC Level 2 AI Implementation Checklist: 10 Actions Before Your Assessment
This CMMC Level 2 AI implementation checklist covers the documentation, technical, and vendor actions that assessors will look for. Work through these before your C3PAO engagement begins.
Policy and Documentation
- 1. Inventory all AI systems in scope — list every AI tool, model, API, and pipeline that processes, stores, or transmits CUI, including shadow AI tools discovered through network monitoring. This inventory feeds your SSP.
- 2. Update your SSP to include AI systems — each AI system in scope needs a system component entry: description, data flows, boundary definition, and applicable controls. Assessors will cross-reference your SSP against what they observe.
- 3. Document a CUI data flow diagram for each AI pipeline — show where CUI enters, how it moves through the model or API, where outputs go, and what controls apply at each stage.
- 4. Conduct and document a risk assessment for each AI system — per 3.11.1, this must be a formal artifact, not a Slack thread. Include threat scenarios specific to AI: prompt injection, training data extraction, model inversion.
Access Controls
- 5. Enforce role-based access to AI systems handling CUI — verify that only authorized users can submit CUI-containing inputs and implement MFA on all AI tool access points within your boundary.
- 6. Disable or restrict AI features in productivity tools that lack CUI controls — Microsoft Copilot, Google Workspace AI, and similar tools require explicit configuration to prevent CUI from being processed outside your authorization boundary.
Logging and Monitoring
- 7. Verify that AI systems produce CMMC-compliant audit logs — logs must capture user identity, timestamp, and the nature of the interaction. Review your AI vendor’s logging documentation and test log completeness.
- 8. Integrate AI system logs into your SIEM or log management platform — logs that exist but aren’t monitored don’t satisfy 3.3.1’s accountability requirement.
Vendor and Supply Chain
- 9. Complete a documented security review for every third-party AI API — confirm data retention policies, encryption standards, and whether the vendor’s terms of service permit CUI processing. Get it in writing.
- 10. Review your CMMC AI governance requirements with subcontractors who use AI tools on your programs — flowdown obligations under DFARS 252.204-7021extend to subs. If a subcontractor is using an AI tool on your contract, their AI controls are your problem.
What Changes Under DFARS 252.204-7021 and the Phase 2 C3PAO Transition
The enforcement timeline is what converts CMMC AI governance requirements from a planning exercise into a contract risk.
DFARS 252.204-7021 is the contract clause that makes CMMC a condition of award. Under the Phase 2 transition, which the DoD CIO’s published timeline indicates will require C3PAO assessments for Level 2 contracts, contractors must demonstrate compliance — not just self-attest. The clause requires contractors to maintain their CMMC status and report changes that affect compliance. An AI system introduced after certification that wasn’t assessed is a potential clause violation.
The Phase 2 transition means that new DoD contracts requiring CMMC Level 2 will mandate a C3PAO assessment rather than an annual self-assessment, per the DoD CIO’s published rollout timeline. Contractors who have been self-attesting under the interim rule need to close the gap between their current SSP and what a third-party assessor will actually examine. AI systems are a known gap area precisely because they’ve been added to contractor environments faster than compliance documentation has kept up.
NDAA Section 1513 adds a separate AI-specific obligation. The provision directs DoD to develop guidance on AI use within the defense acquisition system. Implementing regulations are still in development, and contractors operating under programs subject to Section 1513 oversight should anticipate initial AI use documentation requirements coming into view over the next contracting cycle.
The cost of inaction is concrete: a failed C3PAO assessment delays contract award, triggers a Plan of Action and Milestones (POA&M) process, and can result in contract termination for cause if DFARS 252.204-7021 compliance cannot be demonstrated. For mid-market contractors running on thin program margins, a six-month remediation cycle is not a recoverable event.
AI compliance under CMMC 2.0 is not a future-state problem. It’s a current-state documentation and control problem with a hard deadline attached. Contractors who treat their AI systems as outside the assessment boundary will discover — during their C3PAO engagement — that assessors disagree.