*Insights · AI Governance · Updated 31 Aug 2026*
The first time it landed in front of me, it was a network engineer with a firewall configuration open in one window and a chat window open in the other. A tunnel kept dropping. He pasted the running config in and asked why. He got a good answer in about four minutes, fixed it, and moved on with his day.
He was good at his job. Nothing he did felt like a security decision. That is the part worth sitting with.
By the time I saw it, the configuration for a system inside a CUI boundary was sitting on infrastructure his company did not own, had never assessed, and could not point to on a diagram. There was no policy telling him not to. There was no technical control stopping him. And there was nothing in the SSP that acknowledged the tool existed.
I get asked whether contractors should ban AI tools. That is almost never the right question, and companies that try it end up with the same usage happening on personal devices where they have no visibility at all. The useful question is narrower: which instances of these tools are permitted to touch CUI, who decided that, and where is it written down.
## CUI is not just the documents
The single most common misconception I run into is that CUI means marked documents. Contractors picture a PDF with a banner on it, and they build their thinking around keeping that PDF out of a chat window.
Controlled Unclassified Information is a category of information, not a file format. In a real environment it lives in:
– Source code written against a controlled requirement
– System and device configurations for in-scope infrastructure
– Network and architecture diagrams
– Diagnostic output, logs and error traces from CUI systems
– Statements of work, technical data packages and drawings
None of that arrives with a cover sheet. An engineer troubleshooting a problem does not experience a stack trace as regulated data. He experiences it as the thing he needs to paste somewhere to get help.
That gap between how information is classified and how it is actually handled is where most exposure happens. It is not carelessness. It is a definition that never made it out of the compliance binder and into the working day.
## What the requirement actually says
Under DFARS 252.204-7012 you are obligated to provide adequate security for covered defense information on any system that processes, stores or transmits it. NIST SP 800-171 Revision 2 is the standard by which that is measured, and CMMC Level 2 assesses your implementation of all 110 requirements.
An AI tool that receives CUI is a system component. That is the whole analysis. It is not a productivity add-on sitting outside the scope conversation; it is a place your data goes.
Once you frame it that way, the applicable requirements are the ones you already know:
**3.1.3 — control the flow of CUI in accordance with approved authorizations.** This is the requirement that does most of the work here, and it is the one most contractors have never seriously tested. Pasting into an external model is a CUI flow. If you cannot describe that flow, you have not implemented 3.1.3.
**3.1.1 and 3.1.2 — limit system access to authorized users and permitted transactions.** If a tool is authorized for CUI, access to that instance needs to be limited the same way access to any other in-scope system is.
**3.4.1 and 3.4.2 — establish and enforce baseline configurations.** A consumer account with training-on-by-default is a different configuration from a tenant instance with retention disabled and data residency contracted. Same vendor, different control posture, and only one of them belongs inside your boundary.
**3.3.1 — create and retain audit records.** Most consumer-tier AI usage produces nothing you could hand an assessor.
**3.2.1 and 3.2.2 — make personnel aware of the risks associated with their activities and train them to carry out their assigned security responsibilities.** Generic security awareness training does not cover this. Your engineers need to know which instance is approved and what counts as CUI in the artifacts they handle daily.
Then there is 32 CFR § 170.19. When you categorize assets for a Level 2 assessment, an AI service that processes CUI is a CUI asset. One that is genuinely restricted from CUI but sits inside the environment is a Security Protection Asset or a Contractor Risk Managed Asset depending on its role. Which bucket it falls into is a determination you have to make and document. It is not a determination you get to skip because the tool is new.
## Internal deployment is not automatic safety
A number of contractors have told me they solved this by standing up something internal. Sometimes they have. Often they have moved the problem rather than closed it.
An internally hosted or tenant-isolated model still needs the controls that apply to any system holding CUI. I look for whether access is limited to authorized users, whether prompts and outputs are logged in a way that survives an audit, whether the deployment is in the SSP with a named owner, and whether the retrieval layer respects existing permissions.
That last one catches people. A model connected to a document repository will happily surface content the requesting user was never cleared to see, because the retrieval index does not inherit your file permissions unless somebody built it that way. That is not an AI problem. It is an access control failure with an AI shaped front end, and it will read as a 3.1.1 finding.
## What I would put in place
I would keep this to five things, in this order.
**Decide which instances are approved.** Not which vendors — which instances. Name the specific deployment and configuration that may receive CUI, and state plainly that everything else may not. One sentence per tool.
**Write it into the policy you already have.** This does not need a standalone AI governance program. It needs a paragraph in your acceptable use policy and a line in your SSP. Companies that treat this as a new framework spend six months and produce a document nobody reads.
**Enforce it where you can.** Browser controls, DLP rules on the obvious patterns, blocking unapproved endpoints on managed devices. Imperfect enforcement plus a clear policy is a defensible position. Policy alone is not.
**Log it.** If a tool is approved for CUI, you need to be able to show an assessor how it is used and by whom.
**Train the people who actually touch it.** Administrators, developers, and engineers, with examples from their own work rather than a generic module about phishing.
None of this is expensive. Most of it is a week of decisions that nobody has made yet.
## The pause does not change this
The Department suspended CMMC Phase 2 on 13 July 2026, which removed the November third-party assessment milestone and paused pending implementation across solicitations. A task force is reviewing the program.
What did not change: DFARS 252.204-7012 safeguarding, incident reporting inside 72 hours, Phase 1 self-assessment, SPRS posting, and annual affirmation. Government-led assessments continue.
I would point specifically at the affirmation. When you affirm your NIST SP 800-171 implementation, you are making a representation to the government. The DOJ Civil Cyber-Fraud Initiative has not paused, and False Claims Act exposure for inaccurate cybersecurity representations is the enforcement risk that is actually live right now. If your affirmation says you control the flow of CUI in accordance with approved authorizations, and your engineers are pasting configurations into consumer accounts, those two things do not sit comfortably together.
That is the reason to handle this now rather than after the review reports. Not because an assessor is coming in November. Because you have already signed something.
## Where to start
Ask your administrators and developers which tools they used this month. Not in a policy meeting — individually, without consequence attached, because the answer only helps you if it is honest. Most contractors are surprised by the list.
Then decide which of those may touch CUI, write the decision down, and put a name against it.
—
**Assessing AI risk in your CMMC environment**
If you are working out where AI tools sit against your assessment boundary, I help contractors make that determination, document it so it holds up, and align the controls with NIST SP 800-171. A scope call is thirty minutes and there is no charge for it.
*Nabiha Sofia Herradi is the principal of Cyber DSC, a compliance advisory practice for the Defense Industrial Base. She is a Certified CMMC Professional and holds CISM, CISA, CIPP/E and CIPP/US alongside a law degree, with fifteen years in governance, risk and compliance. Based in Jacksonville, Florida, serving defense contractors nationwide.*