CUI and CMMC AI Governance for BD Organizations (August 2026)

Shadow AI is a growing CMMC compliance risk as organizations adopt AI tools outside approved security-review and CUI-handling processes. It's coming from routine capture work: drafting, competitive research, pipeline tracking, potentially running through tools that were never vetted to determine whether they belong within the organization's CMMC assessment scope. If your BD team is using AI and your CUI and CMMC AI governance framework was built before AI was part of the workflow, there's a good chance your posture has some gaps worth closing.

TLDR:

• Shadow AI is increasingly cited by CMMC practitioners as a potential source of assessment-scope and CUI-handling risk.
• Information may still require CUI protection under applicable laws, regulations, or government-wide policies, even if CUI markings are missing. However, capture plans, pricing models, agency names, contract numbers, and public budget information are not automatically considered CUI.
• If AI handles CUI, it may be included in CMMC scope, requiring review of related systems, data flows, cloud services, retention settings, and SSP documentation.
• FY2026 NDAA Section 1513 requires DoD to develop an AI security framework for DFARS/CMMC, but it does not automatically bring all AI models, datasets, or AI services into current CMMC scope.
• AI platforms built for CUI-scoped BD workflows can run on AWS GovCloud or support Azure self-hosted deployments, keeping data within a controlled boundary with session-level audit logging aligned to NIST 800-171.

Why BD Organizations Face Distinct CUI Exposure Risk

BD organizations handle sensitive government information before formal contract protections are in place, often during pursuit activities where the compliance boundary feels undefined.

• Pre-award capture work routinely involves government-furnished materials and requirements documents carrying CUI markings. Past performance write-ups, pricing models, and technical volumes move through email threads, shared drives, and collaboration tools that may not meet NIST 800-171 baseline controls.
• Teaming creates third-party risk when sensitive information is shared. DFARS 252.204-7012 flowdown requirements apply when subcontractors handle covered defense information or provide critical support.

CMMC Level 2 includes 110 NIST SP 800-171 requirements. AI tools that process, store, transmit, or protect CUI may fall within CMMC scope, depending on their role and architecture, including AI tools used for proposal drafting, competitive analysis, or pipeline tracking.

How AI Tools Expand Your CMMC Assessment Boundary

When AI tools process, store, or transmit CUI, they may become part of the CMMC assessment scope. Assessors may review the tool’s hosting environment, logging, data retention, and whether it operates on FedRAMP-authorized infrastructure.

Where the Boundary Expansion Risk Concentrates

The exposure clusters around a few specific workflow moments:

• Intake and scoping: AI-generated summaries may contain CUI if the source material includes information subject to a CUI authority. Contract numbers, agency names, and public performance specifications are not automatically CUI.
• Draft generation: Pasting prior proposal sections or technical approach language into an AI tool introduces content that may contain controlled technical data or export-controlled material.
• Review and editing: AI editing tools embedded in proposal review workflows may transmit draft content to commercial servers outside any approved CUI boundary.

What Assessors Are Starting to Ask

Coalfire Federal's CMMC AI assessment guidance outlines how tools like Microsoft Copilot and ChatGPT affect assessment scope. Assessors review data flows, hosting environment, data retention practices, contractual coverage, and SSP documentation.

Shadow AI Is a Real CMMC Compliance Risk

BD and capture teams may adopt AI tools without ISSO or security officer review, potentially sending data to commercial cloud services outside approved CUI boundaries. AI-assisted proposal content can contain CUI if the source information is subject to a CUI authority; program names and contract numbers alone do not automatically make information CUI. If CUI is disclosed outside an authorized environment, it should be reviewed under incident-response and reporting requirements and may result in a CMMC finding if required controls were not met.

Where BD Workflows Create the Most Exposure

• Proposal drafting: incumbency data, past performance narratives, and technical approaches pasted into consumer LLM interfaces without review of where that data is processed or stored.
• Competitive research and pipeline tracking: AI summarization tools built into commercial CRM or capture pipeline platforms that have not been reviewed against NIST 800-171 or assessed under a System Security Plan.

If You've Already Processed CUI Through an Unvetted Tool

Discovery that content may have already passed through a consumer AI tool doesn't require panic, but it does require a structured response. The first step is scoping the exposure: identify which tools were used, by whom, during what time period, and what content types were involved. Not every BD document is CUI. Program names, publicly available budget data, and general competitive research typically are not, so a content classification review is the correct starting point before assuming the worst. If that review confirms that covered defense information or other CUI-category content was processed outside an authorized environment, the situation moves into incident-response territory.

Under DFARS 252.204-7012, contractors are required to report cyber incidents to the DoD Cyber Crime Center (DC3) within 72 hours of discovery. Whether an unauthorized AI tool interaction rises to the level of a reportable cyber incident depends on the details: the content involved, the tool's data-handling practices, and whether information was transmitted outside your authorized boundary in a way that constitutes an adverse effect on the information system or the data residing in it. That determination belongs with your ISSO and legal counsel, not your capture team. Engage them immediately and document the conversation.

Regardless of whether a formal incident report is required, the remediation path includes four practical steps: first, preserve a record of what content was submitted and to which tool, to the extent that is recoverable; second, update your System Security Plan to reflect the identified gap and the corrective action being taken; third, brief affected BD and capture team members on what triggered the review and what changes to expect; and fourth, implement an approved tool registry with a standing intake process before any additional AI tools enter the workflow. The goal is not to create a compliance paper trail. The goal is to close the gap that made the exposure possible and show a future assessor that the organization identified and fixed the issue proactively.

What CMMC Level 2 Already Requires When AI Touches CUI

When AI tools process, store, or transmit CUI in BD or proposal workflows, the 110 NIST SP 800-171 requirements apply across the entire data path. Depending on their function and architecture, AI tools handling CUI from RFPs, past performance, or pricing data may fall within the CMMC assessment scope.

A common misconception is that CUI rules apply only to the final proposal. In practice, assessors review the full lifecycle of CUI, including where it enters the environment, how it is processed, where outputs are stored, and whether access controls and audit logging meet SP 800-171 requirements.

The Practices That Create the Most Friction for AI-Assisted BD Work

Three control families generate the most compliance exposure when AI tools enter a BD workflow:

• Access control (AC): When DFARS 252.204-7012 applies and an external cloud service provider stores, processes, or transmits covered defense information in contract performance, the contractor must confirm that the provider meets security requirements equivalent to the FedRAMP Moderate baseline and complies with the clause's applicable incident-handling obligations. Separately, the contractor must satisfy applicable NIST SP 800-171 access-control requirements, including Requirements 3.1.1 and 3.1.2.
• Audit and accountability (AU): Some off-the-shelf AI tools do not produce logs at the granularity NIST 800-171 AU controls require, leaving CUI access events unattributable.
• System and communications protection (SC): Proposal content sent through public API endpoints without adequate encryption or routing controls may create compliance gaps under NIST SP 800-171, including Requirement 3.13.8 for protecting CUI in transit.

The table below maps these control families to the specific failure modes that appear most often in BD environments using AI tools without proper vetting.

Gaps in any of these areas can surface during a C3PAO assessment as findings that affect the contractor's CMMC Level 2 certification and contract eligibility on DoD work requiring CUI handling. BD orgs that adopt AI tools without running them through this control-family lens tend to encounter the exposure at the worst possible time.

The FY2026 NDAA AI Security Framework and Its CMMC Extension

Section 1513 of the FY2026 NDAA directs DoD to develop an AI/ML cybersecurity and physical security framework and integrate it into DFARS and CMMC. Crowell's analysis of the NDAA AI security requirements details the resulting supply-chain risk implications. The provision covers specified AI/ML components and supporting environments, including source code, model weights, training data, and systems used to develop, deploy, store, or host covered AI/ML. Its ultimate scope will depend on DoD's implementing rules.

The NDAA supplements (not replaces) CMMC Level 2. Contractors supporting DoD AI/ML may face additional security requirements as DoD updates DFARS and CMMC, though key implementation details remain pending.

Teams that delay reviewing their AI environments until a final rule is issued may be left reacting to new requirements instead of preparing for them.

Building an AI Governance Framework for a BD Organization

A functional AI governance framework for BD doesn't need to be a compliance document that sits in a SharePoint folder. It needs to be embedded in how capture teams actually work.

Core Components Worth Building

• A data classification decision tree at tool selection, paired with role-specific use policies. Before any document enters an AI tool, the framework should answer whether the content carries CUI, ITAR-controlled data, or proprietary pricing, and that answer gates which tools are permissible. A capture manager running competitive intelligence carries different exposure than a proposal writer, so governance scoped to each role avoids over-restricting one or under-protecting the other.
• An approved tool registry with documented FedRAMP status, deployment model, and CMMC alignment notes for each entry, plus incident logging tied to CUI access events. When a team member routes CUI through an unvetted channel, capturing that deviation reveals where the framework has friction driving workarounds, before an assessor does.

Compliant Deployment Paths for AI Tools That Handle CUI

Deployment must match data sensitivity. Cloud providers handling covered defense information must meet FedRAMP Moderate-equivalent requirements under DFARS 252.204-7012, though FedRAMP authorization alone does not guarantee compliance. Self-hosted environments keep data within the contractor boundary, while air-gapped deployments may be required by contract or export controls. A CUI category or subcategory may impose additional handling requirements.

How GovEagle Supports CUI-Compliant AI Governance for BD Organizations

GovEagle is built for BD organizations operating in CUI environments that need AI governance built into the workflow. The system runs on AWS GovCloud and supports Azure self-hosted deployments, so CUI never leaves a controlled boundary. There are no shared inference endpoints, no training on customer data, and no model calls routed through commercial infrastructure. For teams pursuing CMMC Level 2 or working under DFARS 252.204-7012, that architecture matters before any conversation about AI capability begins.

Where BD teams most often encounter friction with AI governance, GovEagle closes the structural gaps directly:

• Access controls tie to contract and opportunity context, so a BD analyst on an unclassified pursuit cannot pull CUI from a separate CMMC-scoped effort into a shared draft.
• Session-level audit logging gives compliance leads the attributable access record that NIST 800-171 AU controls require without adding manual documentation burden to the capture team.
• Deployment options accommodate air-gapped and SCIF-adjacent environments where commercial SaaS tools are not an option.

GovEagle is FedRAMP Moderate Equivalent, which may satisfy agency requirements depending on contract type and environment. Teams should confirm applicability with their information security, contracts, legal, and program-security personnel, as appropriate to the contract and information involved.

Three Things to Do This Week

For capture managers and ISSOs who want to act on what this post covers, these three steps take less than a day and close the most common exposure gaps:

• Audit which AI tools your BD team used in the last 90 days. Pull a list from IT asset management or a quick team survey. Include browser extensions, writing assistants, summarization tools, and anything embedded in CRM or pipeline platforms. The goal is a complete picture before any tool assessment begins.
• Check whether those tools appear on an approved tool registry. If your organization maintains an approved tool list or SSP-documented toolset, cross-reference it. Tools that processed proposal content but are not on the registry should be flagged for an impact review before continued use.
• Flag any past performance or pricing content that may have passed through unvetted tools for an incident-review conversation. You don't need to declare an incident to have the conversation. Bring your ISSO, legal counsel, and relevant capture leads together, scope what content was involved, and determine whether any CUI-category material requires a formal review. Early scoping is easier than reactive disclosure.

FAQs

Can a BD organization use consumer AI tools for proposal drafting if the content doesn't have CUI markings?

Potentially, but not based solely on the absence of CUI markings. An organization must first determine that the content contains no CUI or other restricted information and that use of the AI tool complies with applicable policies, contractual obligations, and data-handling requirements.

What CMMC Level 2 control families create the most friction when AI tools enter a BD workflow?

Access control, audit and accountability, and system and communications protection tend to generate the most compliance exposure. Cloud-based AI tools that process CUI outside the authorized environment may create deficiencies under applicable NIST SP 800-171 access-control requirements, including Requirements 3.1.1 and 3.1.2. Some off-the-shelf AI tools do not produce audit logs at the granularity NIST SP 800-171 audit requirements may require, and proposal content transmitted to public API endpoints without adequate encryption controls may create compliance gaps under NIST SP 800-171, including Requirement 3.13.8 for protecting CUI in transit.

How should I update my System Security Plan when introducing an AI tool into a capture or proposal workflow?

At minimum, document the specific tool, its deployment model, and the data types it will process; update data flow diagrams to show where CUI enters and exits the AI environment; revise access control entries to reflect which roles can submit CUI-containing content; and capture any new third-party dependencies such as subprocessors or cloud infrastructure endpoints. The cleaner path is a standing intake process: any tool that touches proposal content gets an SSP impact review before active use, not after.

Final Thoughts on CMMC Compliance and AI Governance Across the BD and Capture Lifecycle

AI becomes a CMMC Level 2 scoping consideration when it processes, stores, transmits, or protects CUI or performs a security function for the assessed environment. As CUI and CMMC AI governance increasingly become assessment considerations, BD organizations that build in tool governance, SSP documentation, and user training early are better positioned for compliance. GovEagle supports this approach with AWS GovCloud and Azure self-hosted deployment options, NIST 800-171-aligned audit logging, and access controls tied to contract and opportunity context.