CMMC Is Here, But AI Changes The Compliance Conversation

The defense industrial base has a new habit. Engineers ask a copilot to refactor code. Program teams paste requirements into a chatbot to draft a response. Analysts drop technical notes into retrieval systems so an internal assistant can summarize the chaos. It feels fast. It feels modern. It feels harmless right up until someone remembers what the data actually is. In the defense world, convenience can become spillover in a single paste. And in 2026, that risk lands in the shadow of a compliance regime that is no longer theoretical. CMMC is here. Phase 1 began on November 10, 2025, and runs through November 9, 2026. The compliance clock is ticking while AI adoption is accelerating inside the same contractor environments that store, process, and transmit federal contract information and controlled unclassified information.

That collision matters because CMMC was built to verify that defense contractors can safeguard sensitive information in nonfederal systems, using a structured assessment model tied to the protection of FCI and CUI. The program did not emerge from nowhere. It is the latest chapter in a long DoD effort to reduce persistent weaknesses across the defense industrial base, especially where contractors and subcontractors handle sensitive information outside government-owned systems. The final CMMC program rule states plainly that the program exists to ensure defense contractors are properly safeguarding FCI and CUI on their information systems. At the same time, NIST’s CUI guidance continues to stress that the protection of CUI in nonfederal systems directly affects federal missions and functions.

Now AI has entered the room and moved the furniture around.

The old compliance conversation was centered on endpoints, identity, boundary protection, incident reporting, secure configuration, logging, and access control. Those still matter. But generative AI adds a new layer of exposure that many contractors have not fully operationalized: prompt inputs, conversation histories, uploaded artifacts, retrieved data chunks, embeddings, generated code, model plugins, agent actions, and vendor-side retention practices. NIST’s Generative AI Profile explicitly notes that generative AI risk management spans cloud-based services, large language models, and acquisition, and that organizations need to govern, map, measure, and manage these risks across the AI lifecycle. In other words, AI risk is no longer a side conversation for innovation teams. It is a governance and cybersecurity problem with procurement consequences.

That is where many contractors are about to discover the difference between “using AI” and “controlling AI.”

A machine shop that supports a weapons program may use an external assistant to summarize technical procedures. A software subcontractor may use AI-assisted coding to speed delivery on a defense application. A proposal team may use a commercial model to draft responses that include operational details, architecture language, or controlled program context. A systems engineer may upload troubleshooting logs to an internal retrieval tool that was assembled quickly but never fully scoped for controlled data handling. None of these actions looks dramatic from across the room. But each one raises the same compliance question: where did the data go, who can access it, how is it retained, how is it logged, and can the contractor actually prove control? That question is already embedded in the logic of CMMC, even when the workflow is branded as innovation.

The uncomfortable truth: CMMC controls do not disappear just because the interface looks like a chatbot

CMMC does not care whether sensitive information was mishandled through a legacy file share or a sleek AI assistant. The underlying requirement remains the same: contractors must safeguard the information they are entrusted to handle. NIST SP 800-171 Rev. 3 remains foundational here because it provides recommended security requirements for protecting the confidentiality of CUI in nonfederal systems and organizations. CMMC, in turn, operationalizes assessment against required security measures for contractors in the defense ecosystem. The user interface changed. The accountability did not.

That means leaders should stop asking, “Are we allowed to use AI?” and start asking, “Which AI use cases can be governed at the level required for FCI, CUI, and mission-supporting engineering data?”

That is a different question. It is slower. It is less fun. It is also the question that keeps you out of the headlines.

Where AI changes the compliance conversation

The most important shift is that AI introduces new compliance surfaces inside otherwise familiar environments.

These are not hypothetical concerns. NIST’s Cybersecurity Framework Profile for AI identifies focus areas that include securing AI system components, defending with AI, and thwarting AI-enabled attacks. NIST’s Generative AI Profile also emphasizes lifecycle-wide governance for cloud-based services, acquisition, and large language model use. CISA and its partners, meanwhile, have continued to push secure-by-design approaches for AI and to warn that AI integration creates unique operational security issues requiring logging, monitoring, governance, and explicit contract expectations.

The four contractor questions that matter now

1. What happens when controlled technical data is fed into commercial copilots?

This is the question too many organizations still treat as a training issue instead of a systems issue. Yes, workforce awareness matters. But the larger problem is architectural. If controlled data can be pasted into tools that are not explicitly approved, bounded, logged, and governed for that purpose, then policy alone is a thin wall against operational reality. NIST’s generative AI guidance emphasizes that risk management must account for legal and regulatory requirements, organizational risk tolerance, and use across cloud-based services and acquisition settings. That language matters because it points directly at the defense contractor dilemma: the tool may be convenient, but convenience is not a compensating control.

From a leadership perspective, the issue is simple. A commercial copilot can become a shadow data handling environment. Once that happens, the contractor may struggle to show where sensitive information resides, who processed it, how long it was retained, what controls applied to it, and whether the environment was appropriate for the data category involved. In a CMMC context, that is not just bad hygiene. It is evidence of weak governance.

2. How should contractors govern prompts, retrieval stores, and embeddings?

The AI era has created a new kind of storage problem. The contractor may lock down the source document repository, but then recreate parts of that data in prompts, chat histories, vector stores, embeddings, cache layers, orchestration tools, or model context windows. The original file was governed. The derived AI artifacts often are not. This is one reason CISA’s joint AI deployment guidance and AI integration guidance emphasize secure deployment, asset understanding, monitoring, and explicit definition of AI components and dependencies. The data is no longer only in the folder where leadership thinks it is.

For defense contractors, the practical answer is that prompts and retrieval layers should be treated as governed information handling surfaces, not transient conveniences. If a retrieval system can access CUI, then its ingestion rules, indexing boundaries, access controls, retention policies, logs, and incident response playbooks should be treated with the same seriousness as any other system touching controlled information.

3. What about AI-generated code and AI-assisted engineering?

This is where a lot of organizations are quietly exposed. AI-generated code can accelerate development, but it also complicates provenance, review, and assurance. CISA’s software acquisition materials now include questions about whether suppliers maintain and enforce policies covering the usage of AI-generated code. That detail is telling. It signals that the market is moving beyond “Do you use AI?” toward “How do you govern AI-generated artifacts inside secure development?” Meanwhile, CISA’s secure-by-design posture continues to argue that security should be built into product requirements rather than bolted on after the fact.

For contractors working defense software, the takeaway is blunt: generated code is not inherently compliant code. It is draft material. It still requires secure review, provenance-aware handling, validation against security requirements, and careful human approval before it belongs anywhere near a production or mission-supporting system.

4. Do current contractor practices match the intent behind CMMC?

In many places, no. Or not yet.

GAO reported in March 2026 that DoD still faces implementation challenges in the revised CMMC program and recommended that DoD address external factors that could impede implementation. GAO’s review examined DoD’s support for small companies, acquisition workforce readiness, The Cyber AB’s preparations, and whether DoD has a comprehensive strategy to guide implementation. That matters because compliance success will not be evenly distributed across the defense ecosystem. Prime contractors may build internal governance faster than smaller suppliers, but the security problem does not stop at the prime. If a subcontractor mishandles controlled data through unmanaged AI use, the mission risk still rolls uphill.

This is the part leaders need to hear clearly: AI adoption is moving faster than supplier security maturity. CMMC is arriving while many contractor ecosystems are still deciding whether AI usage belongs in acceptable use policies, procurement reviews, software development standards, architecture boards, or export-control reviews. The answer is yes. It belongs in all of them.

The subcontractor problem will define the next phase of AI compliance

Every prime contractor knows the pattern. Security gets stronger at the center and weaker at the edges. The subcontractor may be brilliant at machining, logistics support, niche engineering, or specialized code. But if that supplier uses unmanaged AI tools to process controlled information, summarize technical requirements, or generate deliverables tied to contract performance, then the compliance exposure expands beyond the organization that clicked “upload.” CMMC exists partly because DoD has long recognized that sensitive information lives throughout a large contractor ecosystem, not just inside top-tier firms.

That makes AI governance a supply-chain issue, not just an internal policy issue.

A prime contractor can no longer assume that a supplier’s general statement about cybersecurity maturity translates into disciplined control of AI-assisted workflows. Supplier questionnaires, flow-down clauses, subcontract requirements, secure development expectations, and data handling rules all need to catch up. The defense market is entering the phase where “show me your AI governance” will become as important as “show me your SSP.”

What a defensible contract or posture looks like

Contractors do not need panic. They need structure.

The strongest posture is not an AI ban and not an AI free-for-all. It is a segmented, use-case-based governance model that ties AI permissions to data sensitivity, contract requirements, technical architecture, and auditable controls.

A defensible approach includes the following:

• Data classification rules for AI use. Explicitly define what categories of data may never be placed into external or unapproved AI systems, including CUI, export-controlled content, sensitive engineering data, incident artifacts, and customer-restricted materials.
• Approved tool boundaries. Maintain an approved list of AI services and configurations, including who may use them, for what purpose, with what data, and under what logging and retention rules.
• Prompt and retrieval governance. Treat prompts, uploads, vector stores, embeddings, and AI memory layers as governed data handling surfaces.
• Human review requirements for generated code and technical outputs. Require review, testing, and provenance-aware approval before generated artifacts enter deliverables or production paths.
• Supplier flow-downs. Extend AI governance expectations to subcontractors and service providers whose tools or workflows may touch contract-related information.
• Continuous monitoring and incident readiness. Align AI use with existing logging, access control, monitoring, and response practices rather than treating it as a side tool outside the security program.

Those steps are consistent with where federal and allied guidance has been heading: secure-by-design development, secure deployment, secure operation, and continuous monitoring for AI-enabled systems.

A practical leadership model

The organizations that handle this well will usually do three things:

This is where executive language matters. AI should not be framed as a toy, a perk, or a marketing bullet. In defense contracting, AI is an information-handling and decision-support capability. That means it belongs inside enterprise risk management, secure engineering, data governance, acquisition review, and compliance oversight.

The real compliance issue is not whether AI is allowed

The real issue is whether the contractor can prove control.

Can the company show which AI tools are approved, which data types are allowed, which users have access, how prompts and uploads are bounded, how retention is managed, how outputs are reviewed, how generated code is validated, how supplier use is governed, and how incidents involving AI-assisted workflows would be detected and reported?

If the answer is no, then the problem is not merely an AI policy gap. It is a maturity gap.

And that is the lesson 2026 is forcing on the defense industrial base. CMMC arrived to verify that cybersecurity is real, repeatable, and assessable. AI arrived to make every weak assumption about data handling faster, easier, and harder to see. One framework is demanding evidence. The other technology is creating new places where evidence can disappear.

That is why the compliance conversation has changed.

CMMC is here. The contractors that succeed will be the ones that understand a hard truth early: in the age of copilots, secure handling of controlled information is no longer just about servers, laptops, enclaves, and accounts. It is also about prompts, context windows, vector stores, generated artifacts, and the quiet paths data takes when nobody is looking. The interface may feel futuristic. The obligation is old-fashioned. Protect the data. Prove the control. Be ready to show your work.

References

Cybersecurity and Infrastructure Security Agency. (2023). Secure by design.
Cybersecurity and Infrastructure Security Agency. (2024). Joint guidance on deploying AI systems securely.
Cybersecurity and Infrastructure Security Agency, Australian Cyber Security Centre, Australian Signals Directorate, and partners. (2025). Principles for the secure integration of artificial intelligence in operational technology.

Cybersecurity and Infrastructure Security Agency. (2024). Software acquisition guide for government enterprise consumers.

Government Accountability Office. (2026). Defense contractor cybersecurity: DOD should address external factors that could impede program implementation (GAO-26-107955).

National Institute of Standards and Technology. (2024). Artificial intelligence risk management framework: Generative artificial intelligence profile (NIST AI 600-1).

National Institute of Standards and Technology. (2024). Protecting controlled unclassified information in nonfederal systems and organizations (NIST SP 800-171 Rev. 3).

National Institute of Standards and Technology. (2025). Cybersecurity framework profile for artificial intelligence (Initial Preliminary Draft) (NIST IR 8596 iprd).

National Security Agency, Cybersecurity and Infrastructure Security Agency, National Cyber Security Centre, and partners. (2023). Guidelines for secure AI system development.

Office of the Department of Defense Chief Information Officer. (2026). Cybersecurity Maturity Model Certification program FAQs.

Office of the Department of Defense Chief Information Officer. (2026). Cybersecurity Maturity Model Certification (CMMC).

U.S. Department of Defense. (2024). Cybersecurity Maturity Model Certification (CMMC) Program, 32 C.F.R. Part 170.

About the Author

Joe Guerra, M.S.-Computer Science, M.S.-Software Engineering, CASP+, CCSP, is a technology and cybersecurity professional committed to advancing secure digital transformation across government and defense missions. His background in software engineering, cybersecurity, artificial intelligence, and technical leadership positions him to contribute to the development of secure, mission-aligned solutions that meet the operational realities of today’s government environment. Through his work with FEDITC, LLC, Joe is part of an organization that supports critical missions worldwide and delivers specialized capabilities in cybersecurity, cloud services, engineering, software, health IT, and infrastructure. FEDITC distinguishes itself through its focus on secure operational execution, including enterprise cybersecurity program support, RMF-aligned implementation, vulnerability management, DevSecOps, mission application development, and continuous improvement practices designed to help units and squadrons field resilient, compliant, and effective technology solutions.

(FEDITC: https://feditc.com/) EMAIL: [email protected]