An AI framework for CMMC is coming, directed by the National Defense Authorization Act for Fiscal Year 2026, and it will layer AI-specific security requirements onto the compliance obligations defense contractors already carry. The framework targets a gap that traditional cybersecurity controls do not close well: the distinct ways artificial intelligence and machine learning systems can be attacked, from poisoned training data to manipulated inputs. This guide explains what the AI framework for CMMC covers, who must comply, the AI-specific controls it points to, and the current status, which has shifted since the framework was first announced.
The central thing to understand is that this is an extension of CMMC, not a separate regime. Contractors already working toward or holding CMMC certification will face additional, AI-specific obligations when AI or machine learning enters the scope of their work with controlled unclassified information, on top of the requirements that already apply. Reading the framework this way, as added layers rather than a parallel program, is what makes preparing for it manageable.
What the AI Framework for CMMC Covers
The AI framework for CMMC originates in the National Defense Authorization Act for Fiscal Year 2026, which directs the Department of War to develop a framework addressing both the cybersecurity and the physical security of the artificial intelligence and machine learning technologies the department acquires. Rather than standing alone, the NDAA instructs that the framework be implemented as an extension of existing departmental cybersecurity requirements and CMMC, so contractors face heightened obligations layered onto current ones, not a second compliance system.
The framework’s scope is defined around “covered AI/ML,” which encompasses the AI and machine learning the department acquires along with its associated components, such as source code, model weights, algorithms, training data, and the software used to develop it. It targets the security risks specific to these systems, three of which recur throughout the framework’s rationale. Data poisoning contaminates the datasets a model trains on, so the model misclassifies information or embeds hidden flaws. Adversarial tampering deliberately compromises the hardware, software, data, or processes behind an AI system. Unintentional data exposure discloses sensitive information through configuration or handling mistakes. The specific statutory provisions and definitions here are drawn from the NDAA and should be confirmed against the current text before relying on them, since the framework itself is still being developed.
Who Must Comply
The obligations reach “covered entities,” meaning organizations that contract with the Department of War for the development, deployment, storage, or hosting of covered AI/ML. That definition captures a broad slice of the defense industrial base, because it turns on the function an organization performs rather than its size. An organization must expect to comply if it develops AI models for defense applications, deploys AI systems in defense environments, or stores and hosts AI services for defense operations.
The reach extends through the supply chain as well. Subcontractors that handle AI or machine learning for prime contractors fall within the same obligations, so a prime cannot treat the framework as its concern alone. For organizations already subject to CMMC Level 2, the practical effect is additive: the 110 security requirements drawn from NIST SP 800-171 that Level 2 already demands remain in place, with the AI-specific requirements added on top once the framework is finalized and incorporated into contracts.
The Core Requirements
The AI framework for CMMC organizes into a set of core requirement areas that extend an organization’s existing compliance program rather than replacing it. The table summarizes them and what each involves.
| Requirement area | What it involves |
|---|---|
| AI inventory and classification | A complete catalog of AI systems that touch CUI, with purpose, data sources, and oversight model |
| AI risk assessment | Continuous, AI-specific risk evaluation across the model lifecycle |
| AI-specific security controls | Input validation, model access controls, output monitoring, and adversarial-attack prevention |
| Documentation | Updated System Security Plan, policies, and Plans of Action and Milestones covering AI |
| Third-party AI tools | Cloud AI that handles CUI must meet the FedRAMP Moderate baseline or equivalent |
The connecting logic across these areas is that AI expands the boundary of what a CMMC assessment covers. Every dataset, model, and AI-generated output that touches CUI becomes part of the assessed environment, which is why the first move is always to know what AI is in use. The following sections take the areas that carry the most weight in turn.
AI Inventory and Classification
A complete AI inventory is the foundation, because an organization cannot secure or document systems it has not identified. The inventory should catalog every AI system that processes, stores, or interacts with CUI, recording each system’s purpose, its data sources, whether it operates autonomously or under human oversight, and whether it was built in house, purchased, or accessed as a cloud service. The most common assessment finding related to AI is undocumented usage, where employees use AI services for CUI-related tasks without the organization’s knowledge, so the inventory is also the primary defense against the single most likely deficiency.
Classification follows inventory, because different AI systems carry different risk. A rule-based tool, a machine learning model, and a system that makes autonomous decisions about CUI each warrant different controls, and mapping them by risk determines where to concentrate effort. Keeping the inventory current is mandatory rather than optional, since new tools appear and old ones retire, and an assessor will look for exactly the undocumented system the inventory is meant to surface.
AI-Specific Security Controls
The framework points to four categories of technical control that address vulnerabilities traditional cybersecurity measures do not cover. Input validation and sanitization defends against prompt injection and similar attacks by filtering inputs before they reach a model and constraining what the model returns, which matters acutely when a model has access to CUI in its context. Model access controls apply least-privilege, role-based access and multi-factor authentication to the models themselves, so not every user can reach every model or capability, and access is tied to role rather than individual.
The remaining two categories govern what the system does and how it is watched. Output monitoring and logging records every interaction with an AI system, capturing who submitted each query, what data was included, and what the model returned, which supports both the audit-logging requirements of NIST SP 800-171 and the incident-response capability an assessment examines. Adversarial-attack prevention hardens the model through continuous validation, anomaly detection, and deliberate adversarial testing, so an organization can catch signs of data poisoning or evasion before they corrupt decisions. Together these controls treat the AI as an asset to be secured, not merely a tool to be used.
Documentation Requirements
Documentation is where the framework meets the CMMC assessment, and the System Security Plan is the central artifact. When AI enters the environment, the SSP must document each AI system within the assessment boundary, describe how it processes CUI, specify the controls that apply, and explain how it is monitored, in enough detail for an assessor to confirm implementation. Policies must extend to AI as well, updating acceptable use to address AI tools, defining approved and prohibited uses, and setting incident-response steps for AI-specific events such as a CUI disclosure to an external model. Elevate’s guide to an AI acceptable use policy that curbs shadow AI covers that policy layer directly.
Plans of Action and Milestones carry AI-related gaps the same way they carry any other, documenting the remediation path, owner, and milestones for controls not yet implemented, within the timeframe CMMC allows. Because AI systems change through updates and retraining, the documentation cannot be a one-time snapshot; it has to reflect the current state, which is why continuous, assessment-ready evidence replaces the periodic pre-audit scramble.
Third-Party AI Tools
Third-party AI carries a specific and firm requirement: any cloud AI component that stores, processes, or transmits CUI must meet the FedRAMP Moderate baseline or an accepted equivalent. Using an unvetted commercial cloud AI service to handle CUI conflicts with DFARS 252.204-7012 and the CMMC program’s requirements, which is a common and serious exposure for organizations that adopt consumer AI tools without checking their authorization status. The practical implication is that an organization must maintain a vetted catalog of approved AI tools with clear configuration requirements, and route CUI-handling AI only to platforms that meet the baseline.
How It Changes Your CMMC Compliance
The AI framework changes the shape of a CMMC engagement more than it changes its foundations. The assessment scope must now include AI systems within the boundary before the assessment begins, so any AI tool that processes, stores, or transmits CUI becomes part of the assessed environment and something an assessor will probe through the SSP, interviews, and system inventory. Contractors should expect to identify every AI tool in use and demonstrate, through technical controls, that CUI cannot flow to AI systems outside the boundary.
The framework also reinforces the shift from periodic to continuous compliance. Because AI systems drift as they are retrained and reconfigured, evidence gathered once before an audit fails to capture the current state, so contractors have to keep assessment-ready evidence year-round. Incident response expands to include AI-specific scenarios, such as an employee leaking CUI into an external model or a model behaving anomalously, each of which needs a defined detection, containment, and remediation path. None of this displaces the existing CMMC requirements; it extends them to a new class of system.
The Current Status and Timeline
The status of the AI framework is the part most often reported incorrectly, so it is worth stating plainly. The framework itself does not yet have an implementation deadline. The NDAA directed the Department of War to develop an implementation plan with timelines and milestones and to deliver a status update to Congress by mid-2026, a milestone that has now passed, which means the current and most reliable guidance on the framework’s timing comes from the department’s latest announcements rather than from the original statute. Contractors should confirm the present status before assuming any particular date, because the framework was still under development when it was announced.
The timeline for CMMC itself, onto which the AI framework will attach, has also changed and must not be described using the original four-phase rollout dates. The phased move to mandatory third-party assessments, often cited as beginning in late 2026, has been suspended, so contractors should not plan around a “Phase 2” third-party deadline. What remains fully in force is substantial and unchanged: the requirement to implement the 110 NIST SP 800-171 requirements, the Level 2 self-assessment and its submission of a score, the underlying DFARS clauses, and the False Claims Act exposure that attaches to an inaccurate self-attestation. Elevate’s analysis of the CMMC Level 2 Phase 2 suspension sets out exactly what changed and what did not. The practical reading is that self-assessment against the 110 requirements is the live obligation today, and the AI framework will layer onto that foundation once it is finalized.
How to Prepare
Preparation begins with an AI inventory, because it is both the first requirement and the defense against the most common finding. An organization should catalog every AI tool in use, including browser extensions, embedded features, and personal accounts, then classify which tools interact with CUI and assess whether each meets the applicable NIST SP 800-171 controls. Tools that handle CUI without meeting those controls must be removed from CUI workflows, and technical controls should prevent unauthorized AI usage from reintroducing the exposure. A structured AI risk assessment is the instrument that turns this inventory into a prioritized plan, and aligning it to the NIST AI Risk Management Framework, whose four functions are Govern, Map, Measure, and Manage, gives the exercise a structure an assessor will recognize.
From there, the work is to segregate CUI operations into compliant, controlled environments, update the System Security Plan and policies to reflect the organization’s AI posture, and build the shadow-AI controls that keep undocumented tools out of CUI workflows. Because the AI framework’s specific requirements are not yet final, its incremental cost cannot be stated with precision, and any figure claiming otherwise is speculation; what an organization can do now is prepare the foundation the framework will build on. That foundation is the same one CMMC Level 2 already requires, which is why the strongest position is to be self-assessment-ready against the 110 requirements today. To map the AI framework to your own environment and build a readiness plan, book a call with an Elevate advisor, and use the CMMC Level 2 master policy compendium for the policy groundwork.
Conclusion
The AI framework for CMMC will extend the compliance obligations defense contractors already carry, adding AI-specific requirements for inventory, risk assessment, technical controls, documentation, and third-party tools once it is finalized. It is an extension of CMMC rather than a separate regime, which means the strongest preparation is a solid CMMC Level 2 foundation with AI systems inventoried, classified, and brought inside the same controls that protect the rest of the CUI environment.
The status matters as much as the substance: the framework has no set deadline yet, the mid-2026 status-update milestone has passed so current guidance should be confirmed, and the CMMC third-party assessment rollout has been suspended, leaving Level 2 self-assessment against the 110 requirements as the live obligation. Organizations that inventory their AI and get self-assessment-ready now will be positioned for the framework whenever it lands. To build that readiness for your environment, book a call with an Elevate advisor.
Key Takeaways
The AI framework for CMMC will layer AI-specific requirements onto existing CMMC obligations, so the strongest preparation is a solid Level 2 foundation with AI brought inside it.
- It is an extension, not a separate regime: directed by the FY2026 NDAA, the framework adds AI-specific requirements on top of the 110 NIST SP 800-171 requirements CMMC Level 2 already demands.
- Inventory is the first move: cataloging every AI system that touches CUI is both a core requirement and the defense against undocumented AI usage, the most common assessment finding.
- The controls are AI-specific: input validation against prompt injection, model access controls, output monitoring and logging, and adversarial-attack prevention address risks traditional controls miss.
- Third-party cloud AI must meet FedRAMP Moderate: any cloud AI handling CUI must meet the FedRAMP Moderate baseline or equivalent, or it conflicts with DFARS 252.204-7012.
- The timeline has changed: the framework has no set deadline, its mid-2026 status milestone has passed, and the CMMC third-party assessment rollout is suspended, leaving Level 2 self-assessment as the live obligation.
FAQs
Q1. What is the AI framework for CMMC? The AI framework for CMMC is a set of AI-specific security requirements directed by the National Defense Authorization Act for Fiscal Year 2026, to be implemented as an extension of existing Department of War cybersecurity requirements and the CMMC program. It addresses the cybersecurity and physical security of the artificial intelligence and machine learning systems the department acquires, targeting risks such as data poisoning, adversarial tampering, and unintentional data exposure that traditional controls do not fully address. It is an added layer on top of existing CMMC obligations rather than a separate compliance regime, and its specific requirements were still being developed when it was announced.
Q2. Who has to comply with the AI framework for CMMC? The framework applies to “covered entities,” meaning organizations that contract with the Department of War for the development, deployment, storage, or hosting of covered AI and machine learning. This includes contractors that build AI models for defense applications, deploy AI systems in defense environments, or host AI services for defense operations, and it extends to subcontractors that handle AI or machine learning for prime contractors. Organizations already subject to CMMC Level 2 face these obligations additively, on top of the 110 NIST SP 800-171 requirements they already must meet, whenever AI enters the scope of their work with CUI.
Q3. When does the AI framework for CMMC take effect? The framework does not yet have an implementation deadline. The NDAA directed the Department of War to develop an implementation plan with timelines and to deliver a status update to Congress by mid-2026, a milestone that has now passed, so the current timing should be confirmed against the department’s latest guidance rather than assumed. Separately, the CMMC program’s own move to mandatory third-party assessments has been suspended, so contractors should not plan around a late-2026 third-party deadline. Level 2 self-assessment against the 110 requirements remains the live obligation today, and the AI framework will layer onto that once it is finalized.
Q4. What AI-specific security controls does the framework require? The framework points to four categories of technical control. Input validation and sanitization defends against prompt injection by filtering what reaches and returns from a model. Model access controls apply least-privilege, role-based access and multi-factor authentication to the models themselves. Output monitoring and logging records every interaction with an AI system to support audit logging and incident response. Adversarial-attack prevention hardens models through continuous validation, anomaly detection, and deliberate adversarial testing. These address vulnerabilities specific to AI systems that traditional cybersecurity controls were not designed to cover, and they apply on top of the existing NIST SP 800-171 requirements.
Q5. Can defense contractors use commercial AI tools with CUI? Only if the tool meets the required baseline. Any cloud AI component that stores, processes, or transmits CUI must meet the FedRAMP Moderate baseline or an accepted equivalent, and using an unvetted commercial AI service to handle CUI conflicts with DFARS 252.204-7012 and CMMC program requirements. The most common assessment finding related to AI is exactly this: undocumented use of consumer AI tools for CUI-related tasks. Contractors should maintain a vetted catalog of approved AI tools with defined configurations, restrict CUI-handling AI to platforms that meet the baseline, and use technical controls to prevent CUI from flowing to unapproved services.