The scenario

The shape of the problem

Someone is drafting a response to a contracting officer. It’s late, they’re tired, and the language isn’t coming. They paste the draft into a chatbot and ask it to tighten the wording. Twenty minutes saved. No policy consulted, no ticket filed, nobody told.

If that draft contained Controlled Unclassified Information, the company has just disclosed CUI to an external system it does not control, cannot audit, and in most cases cannot retrieve the data from.

That is the shape of the problem. Not espionage. Convenience.

The threat model most organizations write for AI is the model behaving badly. The exposure that actually happens first is a person moving data.

Exposure

Four things that go wrong immediately

The data may persist

Depending on the platform and the plan, prompts can be retained, logged, reviewed by humans for quality, or used to improve the service. Consumer tiers behave very differently from enterprise agreements. Most employees have no idea which one they are using, and the interface does not tell them.

The disclosure is invisible

There is no alert when someone pastes a paragraph into a browser tab. Unless you have monitoring looking specifically for it, the first time you hear about the exposure is months later, mentioned casually, by someone who does not realise they are reporting an incident.

Regulatory exposure attaches at the moment of transfer

GDPR, HIPAA, CCPA, state privacy law — whichever regime applies to the data applied the moment it left. The employee’s intent does not change that analysis, and neither does deleting the chat afterwards.

Your access controls do not travel

File permissions, need-to-know restrictions, audit logging — none of it follows the text into a third-party tool. Whatever protection the data carried inside your environment, it lost on the way out.

Defense context

What changes when the data is CUI

For defense contractors this stops being a privacy question and becomes a contractual one.

Under NIST SP 800-171, CUI is meant to live inside a defined boundary with known access controls, monitoring and audit trails. A commercial AI platform is not inside that boundary unless you have deliberately put it there — with an agreement, an assessment and documentation to match.

The practical consequence is uncomfortable. Most contractors have not scoped their AI tools at all, which means employees are routinely using systems that are, on paper, prohibited — and the SSP says nothing about them.

If you have not worked through how scope is determined, the scoping brief in the CMMC series covers the asset categories and why the boundary is an output rather than an input.

Interactive

Can this data go into this tool?

Work through one real combination at a time: a specific category of data, a specific platform. The questions run in the order that matters.

The core problem

The paths nobody has documented

The failure I see most is a policy written against an imagined environment. Leadership believes AI use is limited to a couple of approved tools. The inventory, when someone actually takes one, is always larger.

CUI boundary workstations · mail · file store engineering apps Consumer AI platforms UNRECORDED · UNRECOVERABLE

Method

Building a program that works

The instinct is to ban AI tools. It rarely works. People use them anyway, on personal devices, and you trade visibility for the appearance of control.

1. Inventory what is already in useAsk before writing policy. Survey the team, check network logs and DNS, look at expense reports for individual subscriptions. Make it explicitly non-punitive or you will get a clean and useless answer.
2. Write an acceptable use policy people can followName approved tools. Name prohibited ones. State plainly which categories of information may never enter an external model — CUI, FCI, export-controlled data, personal information, client confidential material.
3. Give people a route to askIf the answer to “can I use this” is silence, the answer people hear is yes. A lightweight intake request, answered within days, prevents most shadow adoption.
4. Approve instances deliberatelyEnterprise agreements with retention terms, tenant isolation and no training on your inputs are a materially different risk profile from a free account. Steer usage toward instances you have actually reviewed.
5. Train on the specific failureGeneric awareness training does not cover this. People need the concrete case: this is what pasting a contract clause means, this is why the marking matters, this is who you tell, and this is why telling us will not get you fired.
6. Reflect it in the SSPApproved AI tooling belongs in the system security plan with its boundary position and controls described. Reality and documentation have to agree.
7. Re-run the inventory on a scheduleAI features arrive inside tools you already own, often switched on by default. An annual review is not frequent enough.

Response

Treating it as an incident type

Add AI disclosure to your incident response plan as a named scenario. Not a subcategory of data loss — a scenario with its own decision path, because the people who trigger it will not recognise what they have done.

• What was disclosed, and was any of it marked or markable as CUI
• Which platform and which account tier — enterprise instance or personal account
• What the provider’s retention terms say for that tier
• Whether contract clauses create a reporting obligation, and on what clock
• Who makes the reporting determination, named by role
• What is preserved as evidence before anyone deletes the conversation

Run it once as a tabletop. The first time you work through the reporting question should not be during a live event with a deadline attached.

FAQ

Common questions

Should we just ban AI tools outright?

You can, but enforcement is the hard part and unenforced bans push usage onto personal devices where you have no visibility. A short approved list with a real request process usually produces better control than a prohibition nobody can police.

Does an enterprise agreement put an AI tool inside our CUI boundary?

Not automatically. The agreement is necessary but not sufficient. The tool has to be assessed, described in the SSP, positioned in your architecture and covered by the relevant controls — the same way any other system handling CUI is.

An employee already pasted CUI into a chatbot. What now?

Preserve what you can before anything is deleted, establish exactly what was disclosed and to which account tier, check the provider’s retention terms, and put the reporting question to whoever owns that determination under your contract clauses. Treat it as an incident until assessed otherwise.

Do we need to worry about AI features inside tools we already use?

Yes, and these are the ones most often missed. Summarisation, drafting and search features get added to existing platforms, sometimes enabled by default. If the platform holds CUI, a new feature that transmits content elsewhere is a change to your environment.

What about our suppliers using AI on our data?

If they handle your CUI, their tooling is part of your story. Flow-down clauses and supplier questionnaires should ask specifically about AI processing rather than relying on a general confidentiality clause written before these tools existed.

How is this different from ordinary shadow IT?

Mechanically it is not, but the adoption curve is much steeper and the entry point is a browser tab rather than an install. Traditional shadow IT controls that key on software installation miss it entirely.

Originally published 11 July 2024. Substantially revised 30 August 2026 to reflect current CMMC and NIST SP 800-171 guidance. Verify current requirements against your contract clauses and published DoD guidance before making decisions about AI tooling.